I have a file - actually a movie - that is causing issues for me. I've swapped the file a couple of times with the same results. The file is 1917. For some reason, this movie constantly pauses every 30-60 seconds for about 2 seconds at a time. This happens when using the HT 5 application for playback. I've confirmed I only have 5-6 language tracks and a couple of subtitles. I've enabled dolby compatibility mode. Everything seems correct in the essential troubleshooting sticky. Now, here's the weird part... if I initiate playback using the native Zidoo plex app? Playback is prestine. Absolutely perfect. Any thoughts on how to troubleshoot this? Sure, I have a workaround, but WHY is this behavior happening? Both the plex and HT 5 path use the same internal playback engine. I'm completely stumped.
Weird - I can't explain why they should behave differently - as you say, both apps simply call the player app. What happens if you play the file using Media Center? When you say you swapped the file, what do you mean? A different file, different source? or a rerip?
Man, you're fast at replying! Media center was a great idea! Just fired it up. Same problem as with HT 5. Got my first pause at about 2:20 in. and again at 2:43. and again at 3:12. HT 5 does not pause at the same places, so those times are just examples. Playing from ht 5, I got my first pause at 2:46, and next at 3:22, and again at 3:48. lastly at 4:16. I tried a different version from an "external source" thinking my rip was corrupted, but they have the same behavior as far as I can tell. For sanity (making sure I'm not going crazy), I started it again in Plex. I'm 5 minutes in with rock solid playback. I've tried disabling VS10 but that doesn't seem to have any impact. I'm absolutely confused by this behavior. But it's 100% repeatable, so there's something going on.
Some would say fast, others would say too much time on my hands But between baking bread, replacing a broken cooker element and learning Italian, I just happened to wander past the PC several times a day... Anyway - yeah, again, weird. But it makes sense at least that HT isn't in the frame. Is there any way you can get that file to me? or a clip of it that exhibits the issue? I feel like a stuck record sometimes, but I've definitely not seen that sort of behaviour!
I'm sure I can figure something out! Give me a moment to get something together for us! I assume I can probably send you a DM with the link?
Ok, now I have the file I thought I'd bring this back to the forum - others may be able to chip in. I downloaded the file and copied it as is to a NAS drive. I'm playing the file from Media Center right now, and so far I'm up to 20 minutes without a blip. If I'm honest, this is exactly what I expected. As I say, the file is on a NAS drive connected to "Ext Hub 1" in the diagram below. The Zidoo is connected to "Den Hub 1" so it runs through 4 switches, two patch panels and a lot of Cat 5 cable to get there and meets approx 100 clients in its journey! If I shark the network, it's quite a busy one! So why does yours pause when played from HT and Media Center but plays fine from Plex? My theory is network vagaries. I don't use Plex and I don't know how the file path works with the inbuilt Plex app on the Zidoo. Common sense would dictate that it's exactly the same as playing from HT or MC, ie the player accesses the file directly. However, maybe the Plex server has a hand in playback? Routed through the server first? I honestly don't know the mechanics of it. So what's the network topography - ie where and how is the file stored in your setup? **edit** By the time I finished the post, playback was up to 30 minutes and counting without a single glitch.
If you suspect that this is something network related, one way to be test would be for those affected to put the file on locally attached media, unplug the Ethernet cable and disable WiFi. If it is network related, it could be quite difficult to track down. Sometimes devices can be affected by whatever else is connected to the network and it can also depend on what services are enabled and being used. Years ago, I found issues in miniDLNA and submitted patches to fix those issues. The problem took several days to manifest (the PVR/STB would run out of network sockets), because miniDLNA was leaking sockets when a buggy UPnP device was attached to the network. In this case, the buggy device was a Yamaha HTR series receiver. If the Yamaha was regularly turned off, you could go for weeks without any issues. If the Yamaha was left on and an HDMI input was selected and active, the issue would take a few days to trigger. If the Yamaha was being used to play files using DLNA from the PVR/STB, or from any other DLNA device on the local network, the PVR would start exhibiting issues after a few hours. In that instance, I was lucky to be able to track the cause down, find the bug in miniDLNA and fix it, because the entire PVR was 95% open source. Obviously I could not fix the Yamaha. Point being - one thing could be caused by something seemingly unrelated. In the case above, one of the first symptoms was slow channel switching and failed scheduled recordings.
So here's my network setup: Ubiquiti Dream Machine w/ 10 GB uplink to Ubiquiti enterprise 10 Gb switch. That switch hosts the plex server and the NAS plus a 1 Gb uplink to the switch in the media room. NAS and Plex are connected at 2.5 Gbps. Zidoo is connected to media room switch at 1 Gb. Everything in the media room is hardwired. From there, the Zidoo runs to an Anthem MRX1140 where audio is processed, then out to a HD Fury Vrroom, then to a MadVR DIY (blackmagic capture card -> VideoProcessor and finally to the Epson LS12000. This setup should be WAY overkill for anything media related. What's odd is this is the only file causing issues that I've stumbled upon. I can't rule out for absolute certain, but it would be a bizarre coincidence to have network issues crop up, not only with this file, but only with this file while playing back from the HT 5 or media browser app, but never manifest when playing back from Plex. I have no issues with any other aspect of the library I've found. But this file is cantankerous. I'm not an expert at the MKV format or keyframes or all of the other specifics that can cause playback issues... I'm open to troubleshooting suggestions / things to check. I'm going to see if I have a spare hard drive lying around. If so, I'll copy the file to that and see if I get any oddities when playing back from the local attached drive. If I do, that will (almost 100%) eliminate network / NAS from contributing. If I get playback errors, it's something else in the chain. Are there any settings that require the Zidoo to be rebooted before they take effect? I turned on Dolby compatibility mode just yesterday as I was troubleshooting this file on my own, but I have not rebooted the device. Just trying to think of any simple things that might explain this bizarre issue.
Ok - on the basis of that equipment and also the fact you only get issues with this one file, I think we can negate a network issue. But yes, worth testing a local drive as @peteru suggested to eliminate it. But given the file plays fine here (And I currently have it running perfectly here again!) I think we can say there's nothing inherently wrong with the file either. The fact that it pauses then resumes seems to indicate a processing issue in one respect or another - does it pause and resume from the same point (which could indicate a player issue) or does it pause and then resume from the time code it would have reached were it not paused? That might indicate an outboard processing problem. Next thing to look at is maybe the MadVR setup - maybe there's something that doesn't like with the way the file is presented? Something like this is a process of elimination - I'd run Zidoo > Anthem > Projector and remove everything else in the chain. I can't see the Vrroom causing this, but I'd still remove it. Favourite is now MadVR.
Ok - so I did the test with the file locally from an external SSD. It played back perfectly. I don't think it's a signal chain issue as other content - more demanding content even - plays back without issue. I can play 4k 60 fps from other sources without issue. UHD discs playback perfectly. Based on the SSD playing back, and going back to the idea of a network issue... One thing popped in my mind. I have - on occasion - noticed some odd behavior with SMB on the synology NAS devices. It seems that over time, the performance degrades. You can restart the SMB service and that will restore performance temporarily. Now, recent DSM versions have addressed much of this, HOWEVER, just last night I noticed great performance over nfs, but inconsistent performance with SMB. I removed the SMB link in media browser and in HT 5.0. I added the NFS share to the paths and... it's too early to say for certain, but I'm 7 minutes in without a pause. I'm going to continue testing this change, but fingers crossed, moving from SMB to NFS seems to have at least dramatically improved if not completely resolved the issue. I wonder if maybe a combination of fragmentation on that file, SMB performance, and possibly some cache operation that may be in place with the plex app? When the plex app was used, you could see the SMB file link when the file was played. Was the file streamed over SMB or over HTTP protocol? So many questions and still curious why the issue never presented with the plex app. I'm now at 10 minutes without a skip. So WORST case, I'm probably 50x better than I've ever encountered with this problematic file? Huge improvement either way.
I wanted to say thank you for chiming in! I really appreciate you engaging to assist! Similar to your other issue, I'm starting to suspect this was an SMB problem. I moved all my links over to NFS from SMB and I'm now at 12 minutes without a single pause.
I didn't respond to this earlier... It was pausing and resuming from the same position. i.e., it would pause at 6:22 for about 1 - 2 seconds, then resume at exactly the same place. It was truly as if someone was pressing pause on the playback and then resuming a second or so later. Thank you again for all your help! I really appreciate the suggestions, dialog, and questions. The input started me down the path of considering the network / NAS component as we continued to pull on the thread. Thank you for that.
I'm so happy to hear that you've got it sorted and that you know where to look for improvements. For what it's worth, I always prefer NFS over TCP when possible, but Samba should be able perform to at least 75% of NFS speed. In theory, that ought to be good for files that have average data rates as high as 700Mbit/s. If you have files that are near that bitrate, you should consider transcoding them to something more sensible for playback on the Zidoo. Such high bitrates would be seen with 4K BRAW footage! I assume that this is not the case with the problematic file because Mark would have called it out. There are many things that can be tuned in smb.conf (not sure how easy that is on a branded NAS), so you may be able to get SMB to perform adequately by tweaking the config. Another thing to check is the detailed SMART stats on all your drives. It could be one flaky spot on one HDD that is causing problems. I assume that you also checked the port stats on your networking equipment to check that there no issues there. Good luck with the rest of the troubleshooting and let us know if you discover something specific. It's always good to add data points to the collective knowledge.
Interesting... I must admit there has been a very consistent common denominator over the many years I've been helping Zidoo when it comes to network issues, and that's been Synology NAS drives. Not that I think there's anything inherently wrong with either the box or the NAS, but simply an incompatibility there somewhere. Interestingly if you use standard Android Jellyfin clients, the stream, although using the native player, is played using http and although I would assume both the Plex and Jellyfin native apps would use direct path, maybe in the case of Plex it's not - I don't know the answer, but there's obviously a difference there. Interesting about NFS. Years (and I'm talking decades!) ago, the preference was always NFS because of the low network overhead - this was in the days of SMB1. Later, while working with Zidoo, we found that NFS was problematic and SMB provided a far more reliable connection - but this was a few years ago - probably around the time of the 1295 boxes, and since then my preference and recommendation has always been SMB as I've never had a problem with it since. But maybe I need to revisit that - I may swap all my test shares over the NFS and see how it goes - obviously a lot has changed on both sides since those heady days.
I noticed when playing natively, the data came directly from the synology, but playing through plex, I get the data through the plex server. My plex server uses nfs. I’m guessing plex reads the data and presents an http stream to the zidoo. That would eliminate smb from the equation - or at least make the “data collection” occur on the plex server. Combine that with probably a local cache that probably also occurs in ram before data is sent over the network to the zidoo and I can see how I got better results.
Great! That makes sense then - I've changed all my shares over to NFS to give that a bit of a test drive on my test box now. Still doesn't really explain why that particular file and not others though.
