media-sound/gmusicbrowser-{1.1.8,9999} & layouts ebuilds

[tclover]

For those interested in a newer gmusicbrowser and gmusicbrowser-art layouts, I've submited a bug for version bump for gmusicbrowser and added gmusicbrowser-layouts ebuild in the same bug.
Screen shots can be found on those two homepage.
This media player is more than promising... with CUE support nothing on *nix can come close to it. Everything is herebug 371943.

[tclover]

This media player does not have OSS4 support but still... it's still better than other ones because gstreamer support with gmusicbrowser is not a mere simple word. You can select your `/dev/dsp*' device in the preferences. Why do you care about such trivial thing? Well, despite the support of gstreamer on the most and the less fancier player out there,--take rhythmbox for example which is not a bad player at all but...,--the gstreamer support mean, and I don't knwo if it's a bug in gstreamer or in those media players, the player output via the default `/dev/dsp*' device defined by gstreamer-properties. In theory that what should happen but every media player I've tried, I repeat myself--rhythmbox in one of the best--, end up by outputing to card0/subcard0--that's mean the first output the first OSS[4] device and even if /dev/dsp' is linked to the right device. The issues is that the first OSS[4] device is hdaudio... for those of us who have a sound card and picked it with a little care to not have a disgusting sound that's too much.

Until merging gmusicbrowser, I was stuck with audacious which has a native OSS4 support--which give a really great sound when it output to a CMI8788 (full DUPLEX SPDIF) than to even HD Audio full DUPLEX SPDIF!--which is still too buggy to my taste. audacious is still too buggy when .cue(+.ape|.flac) file... the seekbar is pratically useless.

So to finish you can select your OSS4 device with it or chose to play your media with mplayer[2] if you want. And of course you can really manage your library and not only be able to do a mere search/filter... which is the meaning of `manage large library' of well known media players.

...still you don't care. I do.

[ashtophet]

Great!

Although my main music player, for a long time, are xmms2 and quodlibet, it's quite refreshing to try something that versatile.

Thank you very much!

P.S.: Of course, shameless shot: http://ompldr.org/vOTQ2Yw

[ppurka]

First, thanks for the ebuilds.

Did you try to give your patches to upstream? squentin can be found on #gmusicbrowser and is very helpful.

Also, you can find -9999 and 1.1.6 ebuild on gmusicbrowser homepage so perhaps you can merge your changes with the ones in the homepage? In fact, the changes I see are the mplayer2 patch (you should probably be using the epatch function and this can be gotten rid of if the changes are merged upstream) and inherit of git-2 eclass (I am not sure what is the difference between git-2 and git eclasses).

The gmusicbrowser-art ebuild has incorrect RDEPEND. It should depend on version >=1.1.6 and not >=1.1.16.

And shameless plug from me too
_________________
emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/

[tclover]

Yeah, I'm just reading your post, ppurka, after correcting that RDEPEND error--I've removed the extra 1 digit that was there!--that errors pulled 9999 version instead of 1.1.6 which is the stable release. I contacted squentin from the beginning, before any idea of submiting any bug, for the mplayer2 `patch'--because it wasn't a patch at that time. I decided later to submit a bug with the ebuilds and then... noticed that the ebuilds was primary made for my local portage tree which made me re-submit new ebuilds--I've removed mplayer2 and titlebar USE flag to not give a headache to the maintainers wich now pull an extra perl binding, that's nothing compared to the hundred pulled by gmusicbrowser if you don't have any. I have mailed squentin after submitting the bug but by now I've updated them for the previous reasons and I don't see any ebuilds on gmusicbrowser.org anymore--there's only a link to official portage tree. And there's no reaction for whatever reasons from the media-sound maintainers.
And here my shameless ss. And I'd like to know how to remove the visual panel... I don't have the time to learn perl... thanks for any input.

EDIT: I see that ashtophet has a preference for that layout too, I do as well. l, however, prefer the way the queue tab was made with that layout reminding me of what I did with a fb2k layout profile--which is my default one--on M$.
And don't post comments of your successful merging on bugzilla...

[ppurka]

[tclover]

[tomk]

Moved from Multimedia to Unsupported Software as the ebuilds are currently not in the Portage tree.
_________________
Search | Read | Answer | Report | Strip

[Satoshi]

I'm the one who made the "upstream" ebuilds, although I stronly recommend merging the two since I didn't really know what I was doing (but they do work).

About the layout visuals, you don't need Perl for the layouts. The layouts have a syntax of their own, which you can learn here: http://gmusicbrowser.org/layout_doc.html (although the docs do need a fairly good update, since some of it is deprecated. I was supposed to work on that but ended up having no time ).
Taking the visuals out is probably very easy. What layout are you using?


And, well, this is my custom layout (available from gmusicbrowser-art): http://ompldr.org/vOTR5MA

[tclover]

Thanks for the inputs, I managed to get rid of the Visual panel/tab wich eat up 100% time of a core! nothing less nothing more on my desktop.

[Satoshi]

[tclover]

[tclover]

I've just updated the live and gmb-art ebuild and added a ChangeLog for that matter!

[tclover]