Print

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

[mattkhan]

I've had MC installed on various linux machines for a long time, it generally works fine for audio but was historically not so good at video & the UX was not one your average user seems likely to put up with (aka family). I retried it again the other day and it's still a really bad time in a few ways. I don't see these points mentioned commonly though so are people just used to them or is there something about what I run MC on that means it's my problem?

From a general UX point of view,  the almost always wrong z index is the main problem. This makes for such a confusing experience, a few examples

* file open dialog (e.g. open media file) => always hidden behind the main window
* click in the search box, start typing => anything you type is ignored because focus has been stolen by the "type to start searching" tooltip which means you really have to click twice twice before typing
* surprisingly/unpredictable child window interaction, e.g. open dsp studio, open options, have dsp studio on top, press esc to close it, options closes instead

basically it seems like there is something fundamentally broken in how UI elements are handled and interact with each other and the desktop/window manager.

Secondly, and more seriously for using MC for video playback, it seems rather unreliable. I'm running as a client to a windows server (due the lack of support for "playback from local file") and played a bluray (so it converts to some format and streams to client over a wired network). I attempted to seek a few times via either dragging the position slider or by keyboard arrow back and forth, this produces 1 hard freeze (force kill MC) and 2 crashes. There's also a particular ugly behaviour when seeking as it appears to freeze (pauses the display, a white bar appears where the lower OSD should be) so it seems like the UI is blocked while it is working out how to seek then only continues drawing once that is resolved & finally moving the mouse so as to get the top OSD to appear behaved extremely irregularly (frequently not able to get the top OSD to appear at all).

This is on "normal" commodity hardware which runs linux fine rather than some tiny/custom PC.

Is it just me or is this normal behaviour for MX on linux?

[JimH]

Which Linux?  Which desktop?  Version of MC?

[Hendrik]

Can't comment on the UI issues, thats for bob.

As for seeking with conversion, thats not a well optimized path to use to be honest. It was built for DirectShow and some special conditions put into place, and I'm not sure if those are all accounted for when doing this in the cross-platform video engine. The difficulty here is that basically you are not seeking on the client, but on the server. I don't think the UI should freeze though, unless there is something peculiar about that with linux.

I'll check the playback with conversion and see what kind of format it actually uses, and maybe swap it to one thats more friendly to seeking as well - or if the server-seeking overrides are actually working as they should.

[mattkhan]

Which Linux?  Which desktop?  Version of MC?

Debian testing
KDE
Latest 30

I'll check the playback with conversion and see what kind of format it actually uses, and maybe swap it to one thats more friendly to seeking as well - or if the server-seeking overrides are actually working as they should.

Thanks for checking

[lepa]

Thanks Hendrik for looking into it. Also to my experience the video part has been little unstable.

[mwillems]

So FWIW, I use a Linux client for video playback, but I have a Linux server rather than a Windows server and use "play local file if available."  In that configuration, client/server video playback works pretty robustly and I and my family have been using it daily for a year or two now.  If I do a whole lot of fast seeking, I can sometimes provoke weird behavior, but I can't usually get MC to lock up at all.

That said, I had a similarly challenging experience when I had a mixture of OSs, which is why I eventually standardized on Linux. 

[mattkhan]

So FWIW, I use a Linux client for video playback, but I have a Linux server rather than a Windows server and use "play local file if available."  In that configuration, client/server video playback works pretty robustly and I and my family have been using it daily for a year or two now.  If I do a whole lot of fast seeking, I can sometimes provoke weird behavior, but I can't usually get MC to lock up at all.

That said, I had a similarly challenging experience when I had a mixture of OSs, which is why I eventually standardized on Linux. 

unfortunately Linux MC has too many gaps to make that a viable option for my server but it's good to know that, if the cross platform gaps are ever closed, it improves the experience. Do you still have the UI oddities in MC itself though?

[mwillems]

unfortunately Linux MC has too many gaps to make that a viable option for my server but it's good to know that, if the cross platform gaps are ever closed, it improves the experience. Do you still have the UI oddities in MC itself though?

I don't see too many oddities, but I do have one UI oddity intermittently where I'm typing in the tagging pane and the tag window will lose focus as I'm typing and I'll have to click into the window again to finish typing, which is pretty irritating and sounds related to your search bar issue. It seems to trigger when the suggested text drop down appears with lots of choices, often when I'm typing in the genre tag.

But other than that I don't have any unusual UI experiences (at least that I recall).  For example, I just tried and I can't reproduce your Open Media File or DSP studio issues on Debian Stable or Arch (both with Gnome).  The open media file dialog spawns correctly on top for me, and DSP studio closes when I hit escape after opening it.

[mattkhan]

But other than that I don't have any unusual UI experiences (at least that I recall).  For example, I just tried and I can't reproduce your Open Media File or DSP studio issues on Debian Stable or Arch (both with Gnome).  The open media file dialog spawns correctly on top for me, and DSP studio closes when I hit escape after opening it.

thanks, I'll put gnome on something here and compare

[Hendrik]

For the next build I've switched converted streaming to a different mode that should be a bit more reliable (as long as you use one of the MPEG-TS formats), however the hang on seek remains. There will be another change coming down later to hopefully resolve that.

The format selection for converted streaming inside MC is also rather rigid (well, no matter how you stream converted, its the same rigidity), and I felt it would be good to have a "smart" mode that doesn't apply needless scaling. But on the other hand you probably shouldn't be using converted streaming in many cases, and we should rather work on fixing the actual reason why you use that instead.

Maybe a special streaming source that can specifically work with BDMV and just stream the right m2ts files to you without transcoding would be easy enough to create. I'll think on that part a bit.

[mwillems]

For the next build I've switched converted streaming to a different mode that should be a bit more reliable (as long as you use one of the MPEG-TS formats), however the hang on seek remains. There will be another change coming down later to hopefully resolve that.

The format selection for converted streaming inside MC is also rather rigid (well, no matter how you stream converted, its the same rigidity), and I felt it would be good to have a "smart" mode that doesn't apply needless scaling. But on the other hand you probably shouldn't be using converted streaming in many cases, and we should rather work on fixing the actual reason why you use that instead.

Maybe a special streaming source that can specifically work with BDMV and just stream the right m2ts files to you without transcoding would be easy enough to create. I'll think on that part a bit.

An approach that might resolve mattkhan's case (and has been a wishlist item for many of us for a long time) is a way to handle crossplatform file paths more elegantly so that the "play local file" client function works when you have a Linux server and a Windows client or vice versa.  It's been discussed a few times over the years, but currently there's no alternative to converted streaming in cross-platform server/client scenarios because there's no way to just "point JRiver at the files" like you can when your server and client are both the same OS. 

I see much better seeking performance and less UI latency on clients that can access the files directly via "play local files" than when the same file is served by the server (even when the server is serving an unaltered file).  That performance increase is basically "free" if there were just a way for MC clients that don't share the same OS filesystem convention to adapt the paths.  I've seen a few other media server software suites that handled this particular issue by allowing clients to specify a filesystem base/stem substitution to resolve the root issue (e.g. swap /mnt/media for E:\media) and then just reversing the slashes/backslashes from there. 

[Hendrik]

In this particular case, access to the files would not resolve the ability to play BDMV on Linux. The same function mentioned above would of course also be able to handle local playback of BDMV. Local access and streaming/playing BDMV are really two topics that are only tangentially related.

[mwillems]

In this particular case, access to the files would not resolve the ability to play BDMV on Linux. The same function mentioned above would of course also be able to handle local playback of BDMV. Local access and streaming/playing BDMV are really two topics that are only tangentially related.

I guess I didn't read mattkhan's post as being confined to BDMV.  At least in my experience the video seeking problems he describes exist with all video formats when the video is being served by the server, even when the server can serve them in original format, if you see what I mean. 

But sorry if I derailed the discussion!

[mattkhan]

I think the Linux board could have a sticky for those things that get asked for repeatedly but we don't have

ie loopback input, bdmv playback, local file access

One day, our (or at least my) wishes will come true!

[JimH]

I think the Linux board could have a sticky for those things that get asked for repeatedly but we don't have

ie loopback input, bdmv playback, local file access

One day, our (or at least my) wishes will come true!

Be careful what you wish for.  Would you like to be an admin?

[mattkhan]

lets me direct priorities right??

[JimH]

lets me direct priorities right??

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

[bob]

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

Sounds like it's transcoding. Check the client media network options.

[mattkhan]

I used the same client each time so shouldn't each server provide the same format?

the setup in this case is

windows library server running in a VM with local storage
windows HTPC which is a client of the server configured to use local files if available (has those drives mapped) and with media network turned on

linux client with video conversion set to MPEG2-TS 1080p AutoFPS

item played is a standard BD (i.e. 1080p) in BDMV format

shouldn't it mean the windows HTPC and the windows VM server perform the same job and should be put under similar load? i.e. read m2ts and convert to the MPEG2-TS format

if so, it suggests something is wrong with the server in the capabilities it has (as a CPU)

[bob]

I used the same client each time so shouldn't each server provide the same format?

the setup in this case is

windows library server running in a VM with local storage
windows HTPC which is a client of the server configured to use local files if available (has those drives mapped) and with media network turned on

linux client with video conversion set to MPEG2-TS 1080p AutoFPS

item played is a standard BD (i.e. 1080p) in BDMV format

shouldn't it mean the windows HTPC and the windows VM server perform the same job and should be put under similar load? i.e. read m2ts and convert to the MPEG2-TS format

Oh I see you are trying to get it to transcode. It's just CPU intensive on the server.

[mwillems]

So do I understand correctly that you're seeing higher CPU usage in the VM server than the bare metal server in your tests?  This might be a red herring, but I've seen a similar situation before: in my case the issue was that the bare metal instance was using hardware acceleration for decoding/encoding the relevant codecs, but my VM didn't have access to hardware acceleration because I hadn't configured it correctly to utilize the necessary hardware of the host.  Could something like that be your issue?

[mattkhan]

So do I understand correctly that you're seeing higher CPU usage in the VM server than the bare metal server in your tests?  This might be a red herring, but I've seen a similar situation before: in my case the issue was that the bare metal instance was using hardware acceleration for decoding/encoding the relevant codecs, but my VM didn't have access to hardware acceleration because I hadn't configured it correctly to utilize the necessary hardware of the host.  Could something like that be your issue?

yes that's what I'm thinking, I need to compare logs with the HTPC to see what the difference is.

Edit: yes so the htpc uses nvenc but the server uses the CPU only, for now I will test the Linux client against the htpc then to eliminate the CPU bottleneck as a factor.

[Hendrik]

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.

Trying yet another streaming mode in the next version that should hopefully work better. It was a bit more work to hook it all up, but testing seemed to go fine. There might be a slight delay as the server responds to seek requests (depending on the speed of your server), but the UI should hopefully remain responsive as well.
Still looking to move the entire seek call to a thread, but thats a bigger change.

[mrpro]

Ubuntu Desktop standard 22.04, (Ubuntu 22.04.2 LTS); Ubuntu Studio 22.04 (Ubuntu 22.04.2 LTS); MC 30.0.87 (64 bit)

I have had severe video problems for the entire life of version 30. Specifically not working: TV playback (HD Home Run); Theatre view; any video playback. All exhibit white screen only.

All worked fine in the earliest versions of vs 30. Problems first started with TV. Playback worked but appeared to render at a reduced frame rate. Subsequent updates did not fix this; then possibly an OS update caused video to exhibit white screen, and white screen only for  Theater view.

I have tried this on multiple Linux machines, all running AMD processors. Results are identical.
Any suggestions would be greatly appreciated.

[Awesome Donkey]

The white screen with theater view is likely the recent issue that starting occurring after a Mesa update in Ubuntu and other Ubuntu-based distros. Right now the only ways around it are to downgrade Mesa (which can be tricky and can easily brick an OS install if done incorrectly) or switching distros to like Debian Bullseye.

https://yabb.jriver.com/interact/index.php/topic,135300.0.html

[mattkhan]

Trying yet another streaming mode in the next version that should hopefully work better. It was a bit more work to hook it all up, but testing seemed to go fine. There might be a slight delay as the server responds to seek requests (depending on the speed of your server), but the UI should hopefully remain responsive as well.
Still looking to move the entire seek call to a thread, but thats a bigger change.

I retried with v87 and it does seem to behave better overall, difficult to quantify but clicking around (i.e. jumping forward or back to some arbitrary point) repeatedly caused no surprising behaviour or crashes so thanks for improving this.

I think the most obvious area where it still struggles is with repeated seeks, e.g. tap right arrow n times. This is really quite slow to respond to the extent you wonder if it is frozen. It doesn't crash or do anything else unpredictable though so it is at least stable/consistent behaviour.

The observed behaviour in this case is like the keypresses aren't debounced/coalesced i.e. I seek forward x second n times, it does n +x second seeks as opposed to 1 or 2 seeks (depending on debounce period and how quickly I press the button). It's certainly much slower than clicking somewhere on the track to jump forward. For me, this operation is more common than a big jump so I'd say this would be a good thing to improve for the end user.

[Hendrik]

I'm planning to move the seeking onto a thread soon, as long as you click the button faster then it can respond to the seek, I think it should then coalesce them to a degree.
Seeking a live-converted stream is inherently a bit slow though, so there is little to be done about that.

Hopefully we'll be able to work on direct access and linux BDMV support later this year after some other projects calm down.

[JimH]

For what it's worth, I watched a couple of movies last night without serious problems, on the IdVR.  12th gen NUC with i3 CPU.  No hardware acceleration.  JRVR.  MC 30.0.83  Blu-ray rips.

MC30 was serving the mkv files from a Win10 machine running MC 30.0.87.  Wired connection.

[bob]

I retried with v87 and it does seem to behave better overall, difficult to quantify but clicking around (i.e. jumping forward or back to some arbitrary point) repeatedly caused no surprising behaviour or crashes so thanks for improving this.

I think the most obvious area where it still struggles is with repeated seeks, e.g. tap right arrow n times. This is really quite slow to respond to the extent you wonder if it is frozen. It doesn't crash or do anything else unpredictable though so it is at least stable/consistent behaviour.

The observed behaviour in this case is like the keypresses aren't debounced/coalesced i.e. I seek forward x second n times, it does n +x second seeks as opposed to 1 or 2 seeks (depending on debounce period and how quickly I press the button). It's certainly much slower than clicking somewhere on the track to jump forward. For me, this operation is more common than a big jump so I'd say this would be a good thing to improve for the end user.

Just for the extra reference point, can you try with Video buffering set off (Media Network Options)?
It reduces the complexity of the seeking (if it works at all which is the main reason video buffering is implemented).

[Hendrik]

Just for the extra reference point, can you try with Video buffering set off (Media Network Options)?
It reduces the complexity of the seeking (if it works at all which is the main reason video buffering is implemented).

That option is irrelevant for the kind of streaming being used for converted video.

[bob]

That option is irrelevant for the kind of streaming being used for converted video.

It bypasses the disk buffering code?

[Hendrik]

Yes, it hands the stream directly to FFmpeg with no additional buffering.