HT5 v4.3.70 ALPHA Test Version

I recall someone mentioning not so long ago that a lot of their problems went away after they replaced their router. There are many millions of routers out there infected by malware. Maybe that's what helped in their case.

You could try an isolation test. Power off router/modem & Zidoo. Only connect router/modem + Zidoo under test. Use Ethernet cables. Temporarily disable WiFi on router/modem. Do not connect other devices. Test only with these devices on the network. If the problem still persists, then the most likely explanation is your networking equipment or your ISP.

 

IMO I'd insist in IP and DNS configuration as most probable cause for such issue. Please test it in an insulate scenario and find a potential duplicate IP in your network. In the case of duplicate IP, normally one of the devices doesn't run.

 

On your computer, go to start, run, then type CMD. At the cmd prompt type ipconfig /all. In the default gateway listing look for an address or network that does not belong to your ip network. If see an a unknown network or IP address, find it and remove it from your network. If all else fails, shut down all the devices in your home that has a ip address associated with it. Go into your router and verify it firmware is up to date. Once done reboot your router or factory reset it. Once the router comes back online, reconnect your devices one-at a time. Next log onto a computer and do a "speedtest.net" to check your network speed and verify your IP bandwidth you pay for. Also, do speedtest.net from your cellphone as well. Do these from a device connected directly to your router.

All of these steps are intended to verify your networks integrity and remove any duplicate IP address from your network. Next connect a cat-6 ethernet cable into your Zidoo device and connect the Zidoo directly into your router and power it on. Go into setup, network setting and write down the ip address and mac address of the device. Change the IP address from DHCP to static. Then go into your router, lan settings and find the IP address of the Zidoo device you wrote down in the DHCP address table. Set it as a static address in the router also. Go back onto your computer CMD prompt and type "PING ip address or PING x.x.x.x. You should get a reply. You should see something like this. The time for the packet to reply is "time<1ms". If this time is over 100ms your network is slow. Otherwise, you are okay.


Pinging 192.168.1.x with 32 bytes of data:
Reply from 192.168.1.x: bytes=32 time<1ms TTL=128
Reply from 192.168.1.x: bytes=32 time<1ms TTL=128
Reply from 192.168.1.x: bytes=32 time<1ms TTL=128
Reply from 192.168.1.x: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.1.x:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

This is how you check and troubleshoot duplicate IP addressing and slow network.

I hope this helps you and the Zidoo community out.

Good Luck.

PM

 

Good idea i test that.

 

I tested to do that to connect zidoo player direct in router with a long network cable cat 6 no difference so it feels like the issue is in router or in the network of the ISP.

 

If that's the case, try a factory reset of the router, contact your ISP. If all else fail, replace your router with a new one. If your ISP supplied you with your router as part of your internet setup (gateway), have them come out and replace it.

Good Luck.

PM

 

Based on the above trace route, the issue is with this ISP at the last trace (#14) before it times out (highlighted). I would contact them to let them know your issue.


IP Details For: 46.59.112.189

Decimal:775647421

Hostname:sto2-p1.sto4-p1.as8473.net

ASN:8473

ISP:Bahnhof AB

Services:None detected

Country:Sweden

State/Region:Stockholms lan

City:Stockholm

Latitude:59.3327 (59° 19′ 57.89″ N)

Longitude:18.0648 (18° 3′ 53.42″ E)

Send them this screenshot as proof that their network is timing out.

you can also ping api.themoviedb.org from cmd on your computer or laptop. See if you get a different IP address than the one seen in the traceroute. That ISP may be blocking ICMP inbound into their network via firewalls.

 

Sorry for all the network jargon as I am a retired network engineer by nature.

Just trying to help.
Good Luck

PM

 

Thank you for sharing, I learned a lot.

 

Your are most welcome. All this information is always useful for everyone!!

 

Do you use a static ip with the google dns? If not can you try that?

 

based on the notes above, tmdb pings look fine but ping to tvdb are slow to respond. I think the issue is with tvdb.com and not the zidoo device.

If it was me, I would connect the Zidoo device directly to the router.
go into the zidoo and launch the google app, then open it to get to google browser and doo a speedtest.net
Another way if you can open a ssh session to access the zidoo cli and see if you can ping those devices from the zidoo cli session.

Based on al the tests that have been seen so far, I do not think the issue is with the Zidoo device.

Good Luck

PM

 

I disagree. ~100ms ping times with 0% packet loss is not the problem.

Either way, the OP should be matching everything against TMDB only to get a consistent set of data. It seems that they can not do that because they are getting poor performance from TMDB, so they tried TVDB, which performs better for them.

Neither of the pings look suspicious, but ping is not a tool that diagnoses every problem.

This could even be a MTU problem, with some piece of equipment along the chain crapping out on large packets.

Given the amount of data already presented by the OP, this is not a name resolution issue either.

 

Understood, 100ms ping time will slow things down. but based on the screenshot that shows TMDB being 23ms I did not think that was the issue. I only see that tvbd pings showing over 100ms response times. I thought I saw a trace route to api.tmdb.com where there was a timeout at one of the hops in a earlier screen shot.

Either way I agree with you that if tmdb is the issue maybe someone at Zidoo can find out what is going on from a tmdb engineer. My next question is has this user tried another box to see if the problem is happening on another box. Has he tested this from a PC or laptop, nvidea shield, apple tv, plex etc?

Thanks

PM

 

Ok today i tried to watch a movie.
While i was scrolling through the list of movies i got thrown back to the top of the list. The list is refreshing every xx? seconds.
Nice but why am i thrown back to the top?
What am i doing wrong or
were is the settings to stop refreshing the list while scrolling! Or set the timing to refresh only once a day.

 

Again, traceroute is a useful tool if and only if all the networking equipment along the path operates correctly, including all the ICMP messaging as originally intended when the protocols were designed. Unfortunately that hasn't been the case since the '90s. Modern networks, especially those that carry a huge amount of traffic or are implementing various security driven policies will silently drop packets that break traceroute.

Here are a few runs, about a day apart, from the same system to TMDB. As you can see, once the traffic enters the Amazon network, traceroute starts having a hard time. That does not matter, TMDB still works well for me, even with ~160ms ping times.

Code:

$ traceroute api.themoviedb.org
traceroute to api.themoviedb.org (65.8.161.37), 30 hops max, 60 byte packets
 1  my.router.net (192.168.12.34)  0.588 ms  0.580 ms  0.696 ms
 2  gateway.nsw.au (114.129.184.1)  2.752 ms  4.091 ms  3.764 ms
 3  * * *
 4  Bundle-Ether41.223.bdr02-ipt-639garde-syd.au.as38195.net (103.200.13.65)  165.874 ms  165.871 ms HundredGigE0-0-1-2.291.bdr01-ipt-55smarke-sjc.us.as38195.net (103.200.13.166)  165.061 ms
 5  equinix02-sfo5.amazon.com (206.223.116.236)  165.226 ms HundredGigE0-0-1-2.129.bdr01-ipt-55smarke-sjc.us.as38195.net (103.200.13.126)  165.147 ms equinix02-sfo5.amazon.com (206.223.116.236)  165.144 ms
 6  52.93.70.186 (52.93.70.186)  166.959 ms equinix02-sfo5.amazon.com (206.223.116.236)  164.425 ms  165.236 ms
 7  52.93.70.180 (52.93.70.180)  166.755 ms 150.222.97.45 (150.222.97.45)  165.194 ms 52.93.70.184 (52.93.70.184)  164.746 ms
 8  15.230.36.166 (15.230.36.166)  167.838 ms 54.240.242.117 (54.240.242.117)  164.332 ms 150.222.97.87 (150.222.97.87)  164.433 ms
 9  15.230.36.146 (15.230.36.146)  164.964 ms 150.222.30.108 (150.222.30.108)  164.949 ms 15.230.36.170 (15.230.36.170)  167.132 ms
10  15.230.36.185 (15.230.36.185)  170.747 ms 150.222.30.62 (150.222.30.62)  166.034 ms 150.222.30.58 (150.222.30.58)  165.769 ms
11  15.230.36.185 (15.230.36.185)  169.691 ms * *
12  * * *
13  * * *
14  * * *
15  * * *
16  server-65-8-161-37.sfo53.r.cloudfront.net (65.8.161.37)  164.478 ms *  164.550 ms

$ traceroute api.themoviedb.org
traceroute to api.themoviedb.org (18.244.214.44), 30 hops max, 60 byte packets
 1  my.router.net (192.168.12.23)  0.397 ms  0.388 ms  0.383 ms
 2  gateway.nsw.au (114.129.184.1)  2.692 ms  4.257 ms  3.073 ms
 3  * * *
 4  * HundredGigE0-0-1-2.292.bdr01-ipt-55smarke-sjc.us.as38195.net (103.200.13.176)  165.649 ms 103.200.15.124 (103.200.15.124)  163.906 ms
 5  HundredGigE0-0-1-2.129.bdr01-ipt-55smarke-sjc.us.as38195.net (103.200.13.126)  165.769 ms equinix02-sfo5.amazon.com (206.223.116.236)  167.665 ms  164.571 ms
 6  52.93.70.184 (52.93.70.184)  167.227 ms 52.93.70.182 (52.93.70.182)  165.131 ms equinix02-sfo5.amazon.com (206.223.116.236)  164.032 ms
 7  52.93.70.186 (52.93.70.186)  168.081 ms 54.240.242.81 (54.240.242.81)  174.947 ms 52.93.70.180 (52.93.70.180)  163.887 ms
 8  54.240.242.41 (54.240.242.41)  174.919 ms 54.240.242.37 (54.240.242.37)  171.477 ms *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

DNS could also be involved. Check this out:

Code:

$ dig @1.0.0.1 api.themoviedb.org +nocomments 

; <<>> DiG 9.18.37 <<>> @1.0.0.1 api.themoviedb.org +nocomments 
; (1 server found) 
;; global options: +cmd 
;api.themoviedb.org.            IN      A 
api.themoviedb.org.     15      IN      A       3.169.231.97 
api.themoviedb.org.     15      IN      A       3.169.231.119 
api.themoviedb.org.     15      IN      A       3.169.231.17 
api.themoviedb.org.     15      IN      A       3.169.231.116 
;; Query time: 2 msec 
;; SERVER: 1.0.0.1#53(1.0.0.1) (UDP) 
;; WHEN: Sat Jul 12 02:05:12 AEST 2025 
;; MSG SIZE  rcvd: 111

$ dig @1.1.1.1 api.themoviedb.org +nocomments 

; <<>> DiG 9.18.37 <<>> @1.1.1.1 api.themoviedb.org +nocomments 
; (1 server found) 
;; global options: +cmd 
;api.themoviedb.org.            IN      A 
api.themoviedb.org.     60      IN      A       18.244.214.44 
api.themoviedb.org.     60      IN      A       18.244.214.79 
api.themoviedb.org.     60      IN      A       18.244.214.88 
api.themoviedb.org.     60      IN      A       18.244.214.89 
;; Query time: 4 msec 
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) 
;; WHEN: Sat Jul 12 02:05:35 AEST 2025 
;; MSG SIZE  rcvd: 111

Two completely different networks returned by a pair of resolvers run by Cloudflare. So, yeah, changing DNS servers on the router might help.

 

Sorry if you have already answered this question, as I've not been following this convo - can I ask where your movies are stored? NAS, DAS, USB etc etc?

 

okay, make sense. Good Work. Don't know if he is using DDNS or if the ISP is using DDNS. I do see in the traceroute that once the packet leaves the gateway and hits the first ISP it goes from 4ms, skips a hop then when hits the first ISP latency jumps to 165ms. In corporate network, my users would be screaming.

 

All movies and series are located on a nas.

 

Those numbers are from my connection. The 165ms figure is actually on the better end of the scale, considering that this is between Australia and USA. Over here, even 250ms pings to USA are considered acceptable. Original poster had much better times, then the traceroute stopped returning results, with the last hop still being in their ISP's network.