G Speed Posted September 28, 2014 Share Posted September 28, 2014 No idea what's happening.... Watching a movie, 30 mins in it freezes... then happens a bit later... random Today happened after 1h:30mins.. it's 100% random Thought it was a data issues or something, but if I rewind back a few seconds it plays fine... Running Beta10, Zero Plugins Watching movie via WDTV Live Player, Wired As far are I can see everything seems to be running fine... when issue happens nothing happens in the log... Network is Router | Server - Switch - AP Wired "Upstars" - WDTV Player Nothing in the network has changed log.txt Quote Link to comment
EMKO Posted September 28, 2014 Share Posted September 28, 2014 i don't know if this is the same problem but i also get movie files freezing on 5.0.5, what i found that fixes the problem is not using //tower but instead //192.168.1.121 the ip for the server i don't know why this works but i don't get files freezing anymore. Quote Link to comment
garycase Posted September 28, 2014 Share Posted September 28, 2014 Are the movies stored in a single "container" file, or are they in DVD .VOB format? If the latter, are you sure the VOBs for the movie are all on the same disk? If not, this could be a spin-up delay when it's switching between VOBs. If that's not it, you're likely having network reset issues. Try re-seating your Ethernet cables, and perhaps using a different switch/router port. Quote Link to comment
Frank1940 Posted September 28, 2014 Share Posted September 28, 2014 Are the movies stored in a single "container" file, or are they in DVD .VOB format? If the latter, are you sure the VOBs for the movie are all on the same disk? If not, this could be a spin-up delay when it's switching between VOBs. If that's not it, you're likely having network reset issues. Try re-seating your Ethernet cables, and perhaps using a different switch/router port. ...AND rebooting the router and all of the switches. (The devices all ran some version of Linux and occasionally they just need a reboot to clear out 'lost memory' segments and any other little corruptions that might creep in after months of continuous operation.) Quote Link to comment
G Speed Posted September 28, 2014 Author Share Posted September 28, 2014 i don't know if this is the same problem but i also get movie files freezing on 5.0.5, what i found that fixes the problem is not using //tower but instead //192.168.1.121 the ip for the server i don't know why this works but i don't get files freezing anymore. Have always used IP lol Are the movies stored in a single "container" file, or are they in DVD .VOB format? If the latter, are you sure the VOBs for the movie are all on the same disk? If not, this could be a spin-up delay when it's switching between VOBs. If that's not it, you're likely having network reset issues. Try re-seating your Ethernet cables, and perhaps using a different switch/router port. All single files ...AND rebooting the router and all of the switches. (The devices all ran some version of Linux and occasionally they just need a reboot to clear out 'lost memory' segments and any other little corruptions that might creep in after months of continuous operation.) Will give it a shot.... and report back after the next movie tonight lol Quote Link to comment
G Speed Posted September 28, 2014 Author Share Posted September 28, 2014 Just want to make sure, all this looks okay Sep 28 17:19:26 Tower dhcpcd[1279]: eth0: carrier lost Sep 28 17:19:26 Tower dhcpcd[1279]: eth0: deleting host route to 192.168.0.191 via 127.0.0.1 Sep 28 17:19:26 Tower dhcpcd[1279]: eth0: deleting route to 192.168.0.0/24 Sep 28 17:19:26 Tower dhcpcd[1279]: eth0: deleting default route via 192.168.0.1 Sep 28 17:19:26 Tower dhcpcd[1279]: eth0: deleting IP address 192.168.0.191/24 Sep 28 17:19:26 Tower dhcpcd[1279]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' NOCARRIER Sep 28 17:19:26 Tower avahi-daemon[1420]: Withdrawing address record for 192.168.0.191 on eth0. Sep 28 17:19:26 Tower avahi-daemon[1420]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.191. Sep 28 17:19:26 Tower avahi-daemon[1420]: Interface eth0.IPv4 no longer relevant for mDNS. Sep 28 17:19:26 Tower kernel: r8169 0000:02:00.0 eth0: link down Sep 28 17:20:29 Tower dhcpcd[1279]: eth0: carrier acquired Sep 28 17:20:29 Tower dhcpcd[1279]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' CARRIER Sep 28 17:20:29 Tower kernel: r8169 0000:02:00.0 eth0: link up Sep 28 17:20:29 Tower dhcpcd[1279]: eth0: using ClientID 01:20:cf:30:64:4e:63 Sep 28 17:20:29 Tower dhcpcd[1279]: eth0: reading lease `/var/lib/dhcpcd/dhcpcd-eth0.lease' Sep 28 17:20:29 Tower dhcpcd[1279]: eth0: rebinding lease of 192.168.0.191 Sep 28 17:20:29 Tower dhcpcd[1279]: eth0: sending REQUEST (xid 0x4ffd978), next in 3.23 seconds Sep 28 17:20:32 Tower dhcpcd[1279]: eth0: sending REQUEST (xid 0x4ffd978), next in 7.67 seconds Sep 28 17:20:34 Tower dhcpcd[1279]: eth0: soliciting a DHCP lease Sep 28 17:20:34 Tower dhcpcd[1279]: eth0: sending DISCOVER (xid 0x8ae28878), next in 4.33 seconds Sep 28 17:20:39 Tower dhcpcd[1279]: eth0: sending DISCOVER (xid 0x8ae28878), next in 7.81 seconds Sep 28 17:20:46 Tower dhcpcd[1279]: eth0: sending DISCOVER (xid 0x8ae28878), next in 16.01 seconds Sep 28 17:20:46 Tower dhcpcd[1279]: eth0: offered 192.168.0.191 from 192.168.0.1 Sep 28 17:20:46 Tower dhcpcd[1279]: eth0: sending REQUEST (xid 0x8ae28878), next in 4.40 seconds Sep 28 17:20:46 Tower dhcpcd[1279]: eth0: acknowledged 192.168.0.191 from 192.168.0.1 Sep 28 17:20:46 Tower dhcpcd[1279]: eth0: checking for 192.168.0.191 Sep 28 17:20:46 Tower dhcpcd[1279]: eth0: sending ARP probe (1 of 3), next in 1.56 seconds Sep 28 17:20:48 Tower dhcpcd[1279]: eth0: sending ARP probe (2 of 3), next in 1.60 seconds Sep 28 17:20:50 Tower dhcpcd[1279]: eth0: sending ARP probe (3 of 3), next in 2.00 seconds Sep 28 17:20:52 Tower dhcpcd[1279]: eth0: leased 192.168.0.191 for infinity Sep 28 17:20:52 Tower dhcpcd[1279]: eth0: adding IP address 192.168.0.191/24 Sep 28 17:20:52 Tower avahi-daemon[1420]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.0.191. Sep 28 17:20:52 Tower avahi-daemon[1420]: New relevant interface eth0.IPv4 for mDNS. Sep 28 17:20:52 Tower avahi-daemon[1420]: Registering new address record for 192.168.0.191 on eth0.IPv4. Sep 28 17:20:52 Tower dhcpcd[1279]: eth0: adding host route to 192.168.0.191 via 127.0.0.1 Sep 28 17:20:52 Tower dhcpcd[1279]: eth0: adding route to 192.168.0.0/24 Sep 28 17:20:52 Tower dhcpcd[1279]: eth0: adding default route via 192.168.0.1 Sep 28 17:20:52 Tower dhcpcd[1279]: eth0: writing lease `/var/lib/dhcpcd/dhcpcd-eth0.lease' Sep 28 17:20:52 Tower dhcpcd[1279]: eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks' BOUND Sep 28 17:20:52 Tower dhcpcd[1279]: eth0: sending ARP announce (1 of 2), next in 2.00 seconds Sep 28 17:20:54 Tower dhcpcd[1279]: eth0: sending ARP announce (2 of 2) Quote Link to comment
G Speed Posted September 29, 2014 Author Share Posted September 29, 2014 35 Mins in movie.. freeze... just like the first one I watched this morning Syslog shows nothing... Quote Link to comment
LateNight Posted September 29, 2014 Share Posted September 29, 2014 I used to have a similar problem but changed my default spin down delay to 2 hours. Quote Link to comment
G Speed Posted September 29, 2014 Author Share Posted September 29, 2014 I used to have a similar problem but changed my default spin down delay to 2 hours. If it was spinning down, then I should be able to see it in the syslog? Quote Link to comment
Frank1940 Posted September 29, 2014 Share Posted September 29, 2014 I used to have a similar problem but changed my default spin down delay to 2 hours. If it was spinning down, then I should be able to see it in the syslog? Well, notification of the spindown of drives does appear in my syslog and they appear to be related to drive spindown after I have finished watching a movie. Quote Link to comment
garycase Posted September 29, 2014 Share Posted September 29, 2014 It's VERY unlikely this is a spindown issue, since the movies are in a single container file ... the player would have to be buffering enough of the movie that the disk wasn't accessed for the length of the spindown timer (almost impossible to conceive that's the case). Quote Link to comment
sureguy Posted September 29, 2014 Share Posted September 29, 2014 It's VERY unlikely this is a spindown issue, since the movies are in a single container file ... the player would have to be buffering enough of the movie that the disk wasn't accessed for the length of the spindown timer (almost impossible to conceive that's the case). Simple enough to test, disable spindown and watch a few movies. Quote Link to comment
Flibblebot Posted September 29, 2014 Share Posted September 29, 2014 What's the length of your dhcp leases? Perhaps try increasing the time or using a static IP for your player? Quote Link to comment
garycase Posted September 29, 2014 Share Posted September 29, 2014 It's VERY unlikely this is a spindown issue, since the movies are in a single container file ... the player would have to be buffering enough of the movie that the disk wasn't accessed for the length of the spindown timer (almost impossible to conceive that's the case). Simple enough to test, disable spindown and watch a few movies. True - but no need to test. That's simply NOT the issue. As the OP noted, the movies are "... All single files " ==> so the file is continuously being accessed. No matter what the spindown setting is, the drive containing the movie is never going to be idle long enough to spin down. G Speed: Is this a new issue? If it's been working in the past, then think very carefully about what you may have changed. Has anything been moved? Did you add any new equipment in the mix? (New router; new cables; new switch; etc.) Did you recently upgrade to v6? (and if so, was this ever an issue with v5?) Anything you can think of that might have changed in the topology of your network may provide a clue as to what's happening. Quote Link to comment
BRiT Posted September 29, 2014 Share Posted September 29, 2014 It's VERY unlikely this is a spindown issue, since the movies are in a single container file ... the player would have to be buffering enough of the movie that the disk wasn't accessed for the length of the spindown timer (almost impossible to conceive that's the case). Simple enough to test, disable spindown and watch a few movies. True - but no need to test. That's simply NOT the issue. As the OP noted, the movies are "... All single files " ==> so the file is continuously being accessed. No matter what the spindown setting is, the drive containing the movie is never going to be idle long enough to spin down. G Speed: Is this a new issue? If it's been working in the past, then think very carefully about what you may have changed. Has anything been moved? Did you add any new equipment in the mix? (New router; new cables; new switch; etc.) Did you recently upgrade to v6? (and if so, was this ever an issue with v5?) Anything you can think of that might have changed in the topology of your network may provide a clue as to what's happening. Nope. The first part of the movie may be able to fit into ram and thus the drive is never accessed while the bits are in ram. It won't be until the drive is idle for the timeout and the memory is fully used before the drive is accessed again. Quote Link to comment
G Speed Posted September 29, 2014 Author Share Posted September 29, 2014 What's the length of your dhcp leases? Perhaps try increasing the time or using a static IP for your player? It's static... It's VERY unlikely this is a spindown issue, since the movies are in a single container file ... the player would have to be buffering enough of the movie that the disk wasn't accessed for the length of the spindown timer (almost impossible to conceive that's the case). Simple enough to test, disable spindown and watch a few movies. True - but no need to test. That's simply NOT the issue. As the OP noted, the movies are "... All single files " ==> so the file is continuously being accessed. No matter what the spindown setting is, the drive containing the movie is never going to be idle long enough to spin down. G Speed: Is this a new issue? If it's been working in the past, then think very carefully about what you may have changed. Has anything been moved? Did you add any new equipment in the mix? (New router; new cables; new switch; etc.) Did you recently upgrade to v6? (and if so, was this ever an issue with v5?) Anything you can think of that might have changed in the topology of your network may provide a clue as to what's happening. Hardware/Network all the same. The only change is going from beta5or6 to 9.. hoping it would help out with the webgui not being able to be access after less than 24hours. Had 9 for awhile, but most of that was watching tv shows... 30-45mins long.. never noticed a problem... Let alone much smaller bitrates so it would be able to cache/buffer a crap load more then a movie..... watched a movie on 9 started doing it... Upgraded to 10, Webgui is great now but skipping is still appearing... Here's the drive that the movies are on.. ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 182 180 021 Pre-fail Always - 5883 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 52 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 100 253 000 Old_age Always - 0 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 791 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 10 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 3 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 49 194 Temperature_Celsius 0x0022 129 115 000 Old_age Always - 21 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0 Quote Link to comment
Frank1940 Posted September 29, 2014 Share Posted September 29, 2014 Are you using NFS or SMB? Try the other protocol and see if the problem is exists. (I have a WDTV box but I stopped using it over a year ago because it didn't properly play BluRay movies in BluRay .iso files that split the movie into more than one .m2ts file.) I now use SMB exclusively for video playing. SMB has received a lot of attention from its developers over the past couple of years and seems to work as well (if not better than NFS). As I recall, there was a lot of discussion about NFS (and some issues that it has) a while back and, apparently, NFS seems to being dying a slow death of neglect on most platforms. If that doesn't seem to help, try increasing the spin down time to an hour. If the problem still exists, note if the time to its occurrence has changed. One thing I want to point out is that there have been very, very few complaints about this issue. Apparently, when and if it happens, it is usually found to be an interaction of various factors, equipment and settings peculiar to a particular setup. UPDATE: Saw your last post while writing this one! Apparently, you are on beta 6. You do realize you posted this into the version 5 support forum. (There is a beta 6 support forum .) It would probably be wise to modify your first post with that fact. Quote Link to comment
G Speed Posted September 29, 2014 Author Share Posted September 29, 2014 Using SMB.. reported my self lol to move to OS 6 duH! Quote Link to comment
garycase Posted September 29, 2014 Share Posted September 29, 2014 True - but no need to test. That's simply NOT the issue. As the OP noted, the movies are "... All single files " ==> so the file is continuously being accessed. No matter what the spindown setting is, the drive containing the movie is never going to be idle long enough to spin down. Nope. The first part of the movie may be able to fit into ram and thus the drive is never accessed while the bits are in ram. It won't be until the drive is idle for the timeout and the memory is fully used before the drive is accessed again. "continuously" was a bad choice of words; but the file WOULD be accessed enough that no spin-down timer is going to expire. NO player that I'm aware of buffers enough of the movie that there wouldn't be any accesses until the spin-down time has expired. Note that the minimum spin-down you can set is 15 minutes -- and the OP has indicated this is NOT the case here. But even at 15 minutes, it's simply not realistic that the player wouldn't access the movie during that time. Quote Link to comment
Frank1940 Posted September 29, 2014 Share Posted September 29, 2014 True - but no need to test. That's simply NOT the issue. As the OP noted, the movies are "... All single files " ==> so the file is continuously being accessed. No matter what the spindown setting is, the drive containing the movie is never going to be idle long enough to spin down. Nope. The first part of the movie may be able to fit into ram and thus the drive is never accessed while the bits are in ram. It won't be until the drive is idle for the timeout and the memory is fully used before the drive is accessed again. "continuously" was a bad choice of words; but the file WOULD be accessed enough that no spin-down timer is going to expire. NO player that I'm aware of buffers enough of the movie that there wouldn't be any accesses until the spin-down time has expired. Note that the minimum spin-down you can set is 15 minutes -- and the OP has indicated this is NOT the case here. But even at 15 minutes, it's simply not realistic that the player wouldn't access the movie during that time. However, I have experienced the issue if I pause the movie for a more than seven or eight minutes. (I have the spindown parameter set at 30 minutes.) The reason for this post is not really that bit of information. The spindown time can actually be set in two different places. The first one is the obvious place--- under the 'Settings' tab, on the "Disk Settings' page. The second place is on the 'Main' page under the settings for each disk. Just click on the disk label (i.e., 'Disk 4') and you will see a place where the spindown time can be set for that disk. I am not sure which setting has precedence if they are different! (I am assuming that version 6beta is the same as ver 5.0.5 in this regard.) Quote Link to comment
G Speed Posted September 29, 2014 Author Share Posted September 29, 2014 True - but no need to test. That's simply NOT the issue. As the OP noted, the movies are "... All single files " ==> so the file is continuously being accessed. No matter what the spindown setting is, the drive containing the movie is never going to be idle long enough to spin down. Nope. The first part of the movie may be able to fit into ram and thus the drive is never accessed while the bits are in ram. It won't be until the drive is idle for the timeout and the memory is fully used before the drive is accessed again. "continuously" was a bad choice of words; but the file WOULD be accessed enough that no spin-down timer is going to expire. NO player that I'm aware of buffers enough of the movie that there wouldn't be any accesses until the spin-down time has expired. Note that the minimum spin-down you can set is 15 minutes -- and the OP has indicated this is NOT the case here. But even at 15 minutes, it's simply not realistic that the player wouldn't access the movie during that time. However, I have experienced the issue if I pause the movie for a more than seven or eight minutes. (I have the spindown parameter set at 30 minutes.) The reason for this post is not really that bit of information. The spindown time can actually be set in two different places. The first one is the obvious place--- under the 'Settings' tab, on the "Disk Settings' page. The second place is on the 'Main' page under the settings for each disk. Just click on the disk label (i.e., 'Disk 4') and you will see a place where the spindown time can be set for that disk. I am not sure which setting has precedence if they are different! (I am assuming that version 6beta is the same as ver 5.0.5 in this regard.) Everything is set the same, regardless this is happening as the file is being accessed lol Quote Link to comment
BRiT Posted September 29, 2014 Share Posted September 29, 2014 True - but no need to test. That's simply NOT the issue. As the OP noted, the movies are "... All single files " ==> so the file is continuously being accessed. No matter what the spindown setting is, the drive containing the movie is never going to be idle long enough to spin down. Nope. The first part of the movie may be able to fit into ram and thus the drive is never accessed while the bits are in ram. It won't be until the drive is idle for the timeout and the memory is fully used before the drive is accessed again. "continuously" was a bad choice of words; but the file WOULD be accessed enough that no spin-down timer is going to expire. NO player that I'm aware of buffers enough of the movie that there wouldn't be any accesses until the spin-down time has expired. Note that the minimum spin-down you can set is 15 minutes -- and the OP has indicated this is NOT the case here. But even at 15 minutes, it's simply not realistic that the player wouldn't access the movie during that time. I'm not talking about buffers on the player side. I'm talking about the built in native linux filesystem buffering that seems to take place. I see what seems to be this happening on my system that has 8 GB ram on unraid. I haven't looked enough at this to validate beyond doubt that is exactly the case. However, here us what i oibserve... If my movie is smaller than that ( 7.7 GB or less ) the drives never seem to be accessed again. If my movie is larger than that or runtime is longer than my idle spindown setting ( 2 hours now ) then I get stuttering/pausing at the exact moment I hear the unraid drives spinning up. Quote Link to comment
G Speed Posted September 29, 2014 Author Share Posted September 29, 2014 True - but no need to test. That's simply NOT the issue. As the OP noted, the movies are "... All single files " ==> so the file is continuously being accessed. No matter what the spindown setting is, the drive containing the movie is never going to be idle long enough to spin down. Nope. The first part of the movie may be able to fit into ram and thus the drive is never accessed while the bits are in ram. It won't be until the drive is idle for the timeout and the memory is fully used before the drive is accessed again. "continuously" was a bad choice of words; but the file WOULD be accessed enough that no spin-down timer is going to expire. NO player that I'm aware of buffers enough of the movie that there wouldn't be any accesses until the spin-down time has expired. Note that the minimum spin-down you can set is 15 minutes -- and the OP has indicated this is NOT the case here. But even at 15 minutes, it's simply not realistic that the player wouldn't access the movie during that time. I'm not talking about buffers on the player side. I'm talking about the built in native linux filesystem buffering that seems to take place. I see what seems to be this happening on my system that has 8 GB ram on unraid. I haven't looked enough at this to validate beyond doubt that is exactly the case. However, here us what i oibserve... If my movie is smaller than that ( 7.7 GB or less ) the drives never seem to be accessed again. If my movie is larger than that or runtime is longer than my idle spindown setting ( 2 hours now ) then I get stuttering/pausing at the exact moment I hear the unraid drives spinning up. Nah... that's not the problem - I also doubt it's buffering to ram Movie 1 first pause at 1h:30ish mins Movie 2 first pause 30ish mins, then twice more Tv Show..42 Mins, not one skip Random, HD looks good, Nothing in Syslog... WDTV Firmware is still the same, Router and Switches all Restarted.. Am I missing something? This was not happening with beta5 or 6 Quote Link to comment
Brucey7 Posted September 30, 2014 Share Posted September 30, 2014 To identify whether it's a WD box problem or an unRAID problem, I would recommend you watch the same movie on a PC hooked up on the same cable perhaps to your unRAID server, if that stalls too then you know it's network or un RAID related (most likely network), if it doesn't stall, as I suspect it won't, then you'll know the problem is with your WD live box. I have been right round this loop myself and given away my WD boxes, tried Plex too, but didn't like the noticeable drop in picture quality. Quote Link to comment
G Speed Posted September 30, 2014 Author Share Posted September 30, 2014 To identify whether it's a WD box problem or an unRAID problem, I would recommend you watch the same movie on a PC hooked up on the same cable perhaps to your unRAID server, if that stalls too then you know it's network or un RAID related (most likely network), if it doesn't stall, as I suspect it won't, then you'll know the problem is with your WD live box. I have been right round this loop myself and given away my WD boxes, tried Plex too, but didn't like the noticeable drop in picture quality. So I watched two episodes of a show First - 35:10 Freeze Second - 41:30 Whole show played without a hitch? I have had a problem like this before in the early versions of os5 beta.. I recall upgrading to the next beta and it worked fine. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.