MPV 0.4.1 Brings Various Bug Fixes

[Daktyl198]

How can CMplayer use mpv if mpv doesn't have a slave mode or API to connect to?..
I would love for mpv to work with SMPlayer some how..

it DOES have an API to connect to (as mentioned above)... some of that API work is included in this 0.4.1 release: "Allow client applications to call mpv_terminate_destroy(NULL)."
Keywords being "client applications"

As for SMPlayer, I believe it will never support MPV for several reasons.
1. They do what was mentioned above, scraping stdout over their "slave mode" and fixing their backend to include proper API calling would probably be too much work for them.
2. All of the features, options, etc of SMPlayer are aimed at MPlayer (and SMPlayer2 aimed at MPlayer2), so short of creating ANOTHER version called SMPV, you'd have to change the entire options/etc layout if the user decided to use MPV instead of MPlayer.
3. other stuff...

That being said, I think we can do much better than SMPlayer anyway, and I would contribute to such a cause but unfortunately my programming skills are fairly non-existent.

[johnc]

The irony is... I have the programming skills but absolutely zero motivation to go and re-invent the wheel with a replacement for SMPlayer.

We seem to have this problem in the Linux world. A program finally matures and is pretty solid and sure enough the community says, "Away with it! Let's redo it all over! Because!"

There are only a couple of things in MPV that are worth keeping and it'd be far better if they could just be merged into mplayer2, but it sounds like the mplayer2 maintainer has totally checked out on life.

[Baconmon]

I think we can do much better than SMPlayer anyway

That would be cool too.. If SMPlayer is unwilling to keep up with the times, then I can move on to some thing else..
I would love to use mpv instead of mplayer.. On SMPlayer, it won't even render h265 videos, but mpv can!.. I haven't tried CPlayer or whatever that one person was talking about.. I usually don't bother using any thing not in the debian repos.. But usually when any thing gets popular enough, it will be in the repos..

[Vidar]

We seem to have this problem in the Linux world.

I know very well what you mean and it seems like it'll stay like this for what looks like a very, very long time.

[Daktyl198]

The irony is... I have the programming skills but absolutely zero motivation to go and re-invent the wheel with a replacement for SMPlayer.

We seem to have this problem in the Linux world. A program finally matures and is pretty solid and sure enough the community says, "Away with it! Let's redo it all over! Because!"

There are only a couple of things in MPV that are worth keeping and it'd be far better if they could just be merged into mplayer2, but it sounds like the mplayer2 maintainer has totally checked out on life.

Well, you don't have to go and reinvent SMPlayer, I just mentioned creating something new because I figured it would actually be less work than making SMPlayer compatible with MPV. If somebody wants to step up and make SMPlayer work with it, then by all means do it. That'd be great! That way, we might even be able to merge SMPlayer and SMPlayer2 (split for MPlayer and MPlayer2 usage on most distros it seems) and just have it switch Options/interface/whatever with whatever backend you use.

A "mature and solid" program does not always mean a "great" program. It could be fundamentally flawed at a low level, among other things, so that it can't go very far or maintenance can become too tedious (I'm sure you know all this, being a programmer). Most of the time the community says to switch to a new program that implements features of an older program, there are definite reasons (more active development is a reason I see a lot).

As for "only a couple of things in MPV worth keeping", there was definitely more cruft ripped out of the MPlayer2 code than there was features put in (which I consider a great thing), and at this point trying to merge MPV features into MPlayer2 would be nigh on impossible I believe.

[magika]

Please remind me why do we need UI again (apart from OSD which we have)?
Awww, ASCII progress bar was very cool

[KellyClowers]

Please remind me why do we need UI again (apart from OSD which we have)?
Awww, ASCII progress bar was very cool

Exactly! 99% of the time when I am playing a video I do not want or need a external UI, which is why I like mplayer/mplayer2/mpv/snappy

[Gusar]

How can CMplayer use mpv if mpv doesn't have a slave mode or API to connect to?

CMplayer is a fork of mpv that has the GUI built directly into the code, there's no core/gui separation, it's all one monolithic app. It does not use the libmpv client API, which is quite new and didn't exist yet when CMplayer was created.

Please remind me why do we need UI again (apart from OSD which we have)?

Quite a few people seem to want/need it. Don't ask me why, I like just having a video window and nothing else. After all, I'm watching the video, not the GUI around it. mpv's OSD and extensive keyboard controls is all I need.

[johnc]

Please remind me why do we need UI again (apart from OSD which we have)?

Do you use a web browser with a UI or do you browse the web with wget and curl?

[Vidar]

Quite a few people seem to want/need it. Don't ask me why

I'd say the vast, vast majority want it. Maybe not the majority of Linux users but most certainly the majority of Windows + OS X users. I'm mostly a Linux user, and I don't necessarily mind that there's no GUI too much, but I like to believe that we're in 2014 and there's no need to use terminals like in the 80s anymore...
Apparently living with an 80s mind set is problem in the Linux world as well. I'm not criticizing anyone, just sharing my frustration. I'd really like to convince more people to use Linux rather than Windows but sometimes it's quite hard.