More > JRiver Media Center 30 for Linux
Is MC genuinely usable for video on linux?
mattkhan:
lets me direct priorities right?? :)
JimH:
--- Quote from: mattkhan on February 24, 2023, 05:50:55 pm ---lets me direct priorities right?? :)
--- End quote ---
You'll be in charge, just like I am.
mattkhan:
Am ready to serve!
Back to the topic at hand, I tried the new version and with gnome. I think I will break out a new topic for that as it does seem to behave more normally under gnome rather KDE is not a good experience. Idk what the relative market share (of gnome Vs KDE) is but would be nice to get MC to play nice with KDE.
On the new streaming mode, I found it quite prone completely freezing the entire MC process. Initial impression is that repeated jump requests cause it to fail badly. Large jumps also confuse it, I had one situation where playback started from a bookmark (somewhere in the middle of the film) so I jumped back to the start, it thought about it for so long I thought it was dead and then started playing with the time reporting it was near the start. The content however was from some time later in the film, ie it was like it had completely lost track of position. I could seek back and forth from that new (wrong) point though. The freezing behaviour makes it v hard to report on what is going on in a systematic/reproducible way unfortunately. I will try some more tests later to try to narrow it down.
bob:
One thing you might try just to get more info is to disable the buffering to disk for video on the client (only linux MC has that option, under Media Network). Then the streaming will be only dependent on network parameters and it's much less complex. YMMV.
mattkhan:
Thanks I'll try it.
I think the freezing is actually coming from the server, I played the same item from one MC instance vs another, both Win 10, one is a ryzen 3600 and the other is a 5600G so the 5600G should be faster (albeit not by loads). I actually see the 5600G sit at 100% CPU (all on MC) when playing to a linux client whereas the other one (the 3600) is at ~10-15% under the same conditions. One major difference is that the 5600G is a VM.
The linux client connected to a server which isn't trying to melt itself behaves fairly reasonably at first glance. It still doesn't handle multiple seeks too well but otherwise first impressions are positive. Is it receiving each command at jump + x seconds and then has to process each one? or is it coalescing those requests so that e.g. if I press right arrow 3 times while it is seeking then it actually just does one jump for 3x the duration?)
All roads do lead back to "can we have local playback" though :) I moved my server to a VM as the server is always on so that means my HTPC can then go to sleep when not in use in order to save power, relying on my HTPC to stream is therefore not possible. I'll have to look into why it burns so much CPU when running in a VM.
For reference
HTPC (3600) JRMark (version 30.0.68 64 bit): 5701
Server (5600G) JRMark (version 30.0.65 64 bit): 4967
so the HTPC does actually report as faster but not really that much
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version