INTERACT FORUM
More => Old Versions => JRiver Media Center 21 for Windows => Topic started by: Claude Lapalme on April 24, 2016, 01:58:43 pm
-
Lately, it takes about 10 seconds for me to regain control of JRiver after stopping the playback of an audio file. Switching tracks and pausing are fine. Also, video files do not display this behaviour.
-
Are you using the latest version of JRiver? (21.0.72)
There was a bug causing this a while back, but it should be fixed now.
If you are already using the latest version, try setting the stop option to "immediate" instead of a fade in the option window (search for "immediate") and see if that fixes it.
-
Hmm ... I do have .72. I just tested with "immediate" and there was no difference ...
-
I have a little more information. I waited for this new build, just in case, but there is no difference (I thought: you never know ...)
The problem occurs in all "local" zones. But if I send a playback command to a zone that uses library server on another computer, everything is fine. So this has to do with my computer somehow. There are three different sound cards on it (the board, a card and a usb one) and they each have a zone, so it's not likely a driver issue.
Any thoughts???
-
I see this on my NUC (Windows 7, MC 21.0.50) from time to time. I'll RDP in to stop playback, and when I do the screen will go white and stay white for perhaps 10 seconds.
-
OK, even though this is not a crash, I am sending a log as this is becoming quite intolerable. I think it has to do with a setting since I uninstalled, but tried playing a files before loading library/settings and there was no problem. Loading another library with my settings still creates that lag. I really hope that someone can help
Please.. powers that be ...
-
There are three different sound cards on it (the board, a card and a usb one) and they each have a zone, so it's not likely a driver issue.
Any thoughts???
this might have something to do with it. Not the drivers necessarily but the 3 sound cards. What playback device is selected in Windows?
Do you have the WDM driver installed/selected. Is this a client PC (no server checked in Network Options) .. do you have more than one instance running JRiver as a media server? Are you running zoneswitch rules?
-
this might have something to do with it. Not the drivers necessarily but the 3 sound cards. What playback device is selected in Windows?
I have five devices connected to my system (two PCIe sound cards, one USB, on-board audio, and HDMI) and I'm not seeing this issue, it shouldn't be a problem.
-
this might have something to do with it. Not the drivers necessarily but the 3 sound cards. What playback device is selected in Windows?
Do you have the WDM driver installed/selected.
Is this a client PC (no server checked in Network Options) .. do you have more than one instance running JRiver as a media server? Are you running zoneswitch rules?
Never was an issue before. Also, any of those cards will display this behaviour. WDM is installed, but not in use. Computer in question is a server, and there is no Zone Switch used on it. (A library client does use Zone Switch)
BUT!
I have found more details concerning this behaviour. If I scrub any file forward, even a file that lasts less than a minute, the lag does not occur. Any file longer than a minute displays that behaviour only if I try to stop it after less than its first 30 to 40 seconds depending on the file; it then stops just fine if I let play longer before stopping. It took me a while to realize that as I was sampling different files and often stopping after 15 seconds or so. It's the oddest thing ...
-
I'm bumping this because I've literally tried everything. Is the log showing anything suspicious (since it's not a crash)?
Any further help would be appreciated
Thanks
-
0009297: 5356: TV: CTVRecordingManager::Process: Start
0009297: 5356: TV: CTVRecordingDatabase::GetActions: returning 0 actions
0009297: 5356: TV: CTVRecordingManager::PerformBackgroundTasks: Silent Days ago 0.2171657986109494, dialog days ago 174.9486820023157634
0009297: 5356: TV: CTVRecordingManager::PerformBackgroundTasks: checking program cleanup timer. Last cleanup 0.149997375306545 hours ago
0009297: 5356: TV: CTVRecordingManager::Process: returning because TV device list has not been initialized, and there are no recording actions
0009297: 5356: TV: CTVRecordingManager::Process: Finish (0 ms)
try turning off TV as a feature??
Also seems like you have some kind of repeating process going on returning a "failed to read preamble" message ... a "shared" plugin line item seems to be looping.
Not sure if this would affect audio, but I'd try disabling podcast and TV stuff to see if the audio lag disappears. Then again I have no idea what a preamble message is or which plugin you are sharing ... not that great with logs
-
I have found more details concerning this behaviour. If I scrub any file forward, even a file that lasts less than a minute, the lag does not occur. Any file longer than a minute displays that behaviour only if I try to stop it after less than its first 30 to 40 seconds depending on the file; it then stops just fine if I let play longer before stopping. It took me a while to realize that as I was sampling different files and often stopping after 15 seconds or so. It's the oddest thing ...
Are you using the MC "play from memory" feature?
-
Are you using the MC "play from memory" feature?
I tested with and without already, with no difference
-
0009297: 5356: TV: CTVRecordingManager::Process: Start
0009297: 5356: TV: CTVRecordingDatabase::GetActions: returning 0 actions
0009297: 5356: TV: CTVRecordingManager::PerformBackgroundTasks: Silent Days ago 0.2171657986109494, dialog days ago 174.9486820023157634
0009297: 5356: TV: CTVRecordingManager::PerformBackgroundTasks: checking program cleanup timer. Last cleanup 0.149997375306545 hours ago
0009297: 5356: TV: CTVRecordingManager::Process: returning because TV device list has not been initialized, and there are no recording actions
0009297: 5356: TV: CTVRecordingManager::Process: Finish (0 ms)
try turning off TV as a feature??
Also seems like you have some kind of repeating process going on returning a "failed to read preamble" message ... a "shared" plugin line item seems to be looping.
Not sure if this would affect audio, but I'd try disabling podcast and TV stuff to see if the audio lag disappears. Then again I have no idea what a preamble message is or which plugin you are sharing ... not that great with logs
Thanks for trying. Turning off TV did nothing, but that looping plugin seems interesting. I'll send the log with your message to the powers that be. Who knows ...
-
Over the past few months I went back to this issue from time to time. Finally, I found out that the behaviour stopped when changing the default browser from Chromium to Explorer in MC's Tree and View settings. Why on earth would it do that???
-
I have had the exact same problem for quite some time: MC (22.0.74 today) freezes for about 10 secs when stopping play (but not when pausing), and it has been pretty irritating.
Thanks a lot, Claude, for figuring out a fix: switching from Chromium to Explorer in Tree/View Web browser solves the problem. Just like you, I am quite baffled by the solution...
-
Appreciate the fix. Had the same thing going on.