Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[RFB]

I'm having a problem that started right after I upgraded to Windows 8.1. Windows now likes to turn off power to the USB port and hub I'm using to connect the external drive that holds my music library. The effect of this is if I'm listening to tracks that are longer than 5 minutes, Windows will sometimes (but not always) shut off power to the hub. This results in an interruption in music playback as MC waits for the drive to spin back up to load the next track. This is very jarring with gapless music tracks.

I've already made sure that power saving mode is turned off on the external drive. I also went into Device Manager and made sure that "Allow Windows to turn off this device to save power" is unchecked for all the USB Root Hubs. In the power plan for the computer I made sure that USB selective suspend is disabled and that "Turn hard disks off after:" is set to never.

Still, Windows is sometimes turning off the hub or the drive itself if it isn't accessed for more than 5 minutes. I even tried playing music in iTunes (J River Media Center is my main player) and it does the same behavior.

I also switched to another USB drive (both the drives are Seagates but different models) that also has a copy of my music library (changing the drive letter and path to match the other drive) and the behavior is the same, so I don't think it's the drives.

I can't think of anything else to do and I'm thinking this is a bug in 8.1. Searching online doesn't turn up anything on this issue yet.

[6233638]

Are you sure it's the hub being powered off and not the drive spinning down? It may be doing that itself in an effort to save power. My Western Digital drives don't do this.
 
 
I have been pushing for changes to memory playback that would prevent this interruption from happening, but the JRiver team seem happy with the new memory playback feature as it is. On my system, it's a serious regression from MC18. (much higher memory usage, ridiculous CPU usage, skipping during playback with it enabled)

What I would like to see, is memory playback going back to caching the file rather than decoded audio - at least a 50% memory saving right there - and use that freed up memory to cache the current and next track in memory.
That way you have the entire duration of a song to wait for the drive or network connection to become available and load up the next track, and playback should no longer be interrupted by things like that.

[RFB]

I have power saving mode disabled on both the USB drives. So I would think they wouldn't spin down?

[6233638]

I have power saving mode disabled on both the USB drives. So I would think they wouldn't spin down?

Would Windows' setting override that behavior if it's the drive itself choosing to spin down when idle?

[RFB]

Would Windows' setting override that behavior if it's the drive itself choosing to spin down when idle?

Both drives came with software to turn on/off the power saving mode on the drive itself. I have it set to off.

Also, I have reverted to using MC18 and I haven't encountered the problem yet. Like I said, I was experiencing it with both MC19 and the latest version of iTunes.

[RFB]

With the latest update. 19.0.58, this problem seems to be gone (coincidentally or not).

[glynor]

I just wanted to note that I also upgraded my HTPC to Windows 8.1 this past week.  I've had essentially no problems with MC.

Girder 5, however, is another story... 

[RFB]

Well, unfortunately, this problem came back. I was able to counteract it by using KeepAliveHD, a program that writes a small text file to a drive at an interval you set. I was happy with that.

https://keepalivehd.codeplex.com/

However, I came across a post on an MSDN page that gives a registry edit to address this issue. I've tried it and it seems to be working.

http://blogs.msdn.com/b/usbcoreblog/archive/2013/11/01/help-after-installing-windows-8-1-my-usb-drive-disappears-or-file-transfers-stop-unexpectedly-r-a-post-title.aspx?CommentPosted=true#commentmessage