Topics

Made this for my own use, perhaps somebody else will also find it useful:

Precache plugin loads the next song (or its beginning) into VM cache in order to aid gapless playback.

Requires vmtouch.

With mpv (and possibly gstreamer, not entirely sure about that) gapless mode works by keeping the audio buffer (which is provided by the sound driver - PulseAudio, ALSA, etc) open between the time when mpv finishes playing one file and starts playing the next. If mpv can open and start reading the next file in the few milliseconds it takes for the sound driver to process the remaining contents of the buffer, you get a gapless transition. If your music library is on a disk that is slow or busy, opening the file might take too long and you get a gap between songs. Precache eliminates disk latency from the equation by ensuring that the next file is loaded into virtual memory (i.e. RAM) before it is time to open it.

My music library is located on an external HDD which spins down after some idle time. If the HDD is woken up by gmusicbrowser (starting playback or scrolling around the playlist which involves loading cover art), the program becomes completely unresponsive for the several seconds it takes for the HDD to spin up again. Would it be possible to somehow put file loading in the background so that gmb would remain interactive while waiting for the disc to spin up?

I've recently started experimenting with mplayer audio backend for gmusicbrowser as it offers greatly reduced CPU usage compared to gstreamer (mplayer2 uses 0-2 % CPU where gstreamer got 10-20). The biggest annoyance in this switch is the loss of gapless playback. As I understand it, gmusicbrowser currently starts a new mplayer process for each song, killing and restarting it at every track transition, which is responsible for most of the gap. The reason for this was explained in an earlier thread:

This is because last time I tried with mplayer in slave mode, I couldn't get a signal (output) telling me that the track was finished. By using one process per track, the process ends when the track ends.

But I've found that mplayer does send an EOF signal at a higher verbosity setting. Launching mplayer with

Code Select Expand

mplayer -msglevel all=1:statusline=5:global=6 ("global=6" is the important part) generates "EOF code: 1" when it reaches end of file. The codes apparently mean different things, although I couldn't find any documentation on them, so simply listening for lines starting with "EOF code:" should be sufficient.

Assuming gmusicbrowser can detect that, a single mplayer process should be started with "-idle" flag, and files fed to it by issuing:

Code Select Expand

loadfile "/path/to/file.mp3"

Better yet, in order to take advantage of mplayer2's "--gapless-audio" option, gmusicbrowser should also inform it of the next item in the playlist (probably when the current one starts playing) by also sending

Code Select Expand

loadfile "/path/to/next_file.mp3" 1 where "1" is the "append" option as explained here.

Granted, even the --gapless-audio option is still experimental and imperfect (there's a short clicking noise at track transition on my system), but in any case this should be a vast improvement over the current kill-restart cycle. So the question is: did you just overlook the EOF code output, or is there something else preventing such implementation?

Yesterday I ran a system upgrade that installed the new gstreamer 1.0.2 alongside the old 0.10 version. As I understand, the update was structured so that both versions and their respective APIs should coexist and function normally, but it seems to have broken gstreamer support in gmusicbrowser. Here's the terminal output when trying to play something though gstreamer:

Code Select Expand

CRITICAL **: gst_is_missing_plugin_message: assertion `GST_IS_MESSAGE (msg)' failed at /home/justas-arch/gmusicbrowser/gmusicbrowser_gstreamer-0.10.pm line 104.
CRITICAL **: gst_is_missing_plugin_message: assertion `GST_IS_MESSAGE (msg)' failed at /home/justas-arch/gmusicbrowser/gmusicbrowser_gstreamer-0.10.pm line 104.
GLib-GObject-WARNING **: specified class size for type `GstAlsaSrc' is smaller than the parent type's `GstAudioSrc' class size at /home/justas-arch/gmusicbrowser/gmusicbrowser_gstreamer-0.10.pm line 186.
GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed at /home/justas-arch/gmusicbrowser/gmusicbrowser_gstreamer-0.10.pm line 186.
GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed at /home/justas-arch/gmusicbrowser/gmusicbrowser_gstreamer-0.10.pm line 186.
GLib-GObject-CRITICAL **: g_type_add_interface_static: assertion `G_TYPE_IS_INSTANTIATABLE (instance_type)' failed at /home/justas-arch/gmusicbrowser/gmusicbrowser_gstreamer-0.10.pm line 186.
GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed at /home/justas-arch/gmusicbrowser/gmusicbrowser_gstreamer-0.10.pm line 186.

(gmusicbrowser.pl:5525): GStreamer-CRITICAL **: gst_element_register: assertion `g_type_is_a (type, GST_TYPE_ELEMENT)' failed
Playing error : Can't create sink 'alsa'

I understand that transitioning to the new API would take time and require the perl bindings to be updated first, but I wonder if this particular issue of not recognizing the installed 0.10 libraries is something that can be fixed "locally" in GMB, or is it also something that would require changes from upstream.

One feature I miss from other players (namely, foobar2000) is "stop after current song" functionality. I imagine it should be something as simple as adding a condition check when a song ends and not going forward in playlist/queue if the mode is turned on, though I couldn't find where to put that check without breaking anything.

There's some sort of bug in the way "Threshold to count song as played" setting is interpreted. For example, setting it to "60% or 300 seconds" makes it that songs longer than 300 seconds never get registered as played. I imagine the expected behaviour is to check whichever condition is reached first, so that a 3:20 song is counted as played at 2 minute mark (60%), while a 15:00 one would be counted at 5 minutes (300 seconds). I don't have time to look at the code, so I'm reporting it here.

This happens in layouts like "Playlist, Library & Context": when double-clicking a song in SongList with the option activate=addplay, it is added to playlist twice. It's been like this for at least several weeks now, presumably since this update, though I'm not sure. Admittedly it's not that much of a problem since alternatives (enter, spacebar, drag-and-drop, etc) work normally.

I can't seem to find a way to have the album art size vary depending on the group's size, similar to how it's done in SongList. Here's the relevant bits from my group skin configuration:

Code Select Expand

pic: +aapic(y=title:y,picsize=if($nbsongs<3,picsize/2,picsize),ypad=2)
pic2: -aapic(y=title:y,picsize=picsize/2,ypad=2)

picsize : OptionNumber(default=100,min=0,max=1000,step=10)

It should display a half-sized cover picture if there are less than 3 songs in the group when expanded, and always half-sized when collapsed. However, the check for $nbsongs in that particular context seems to break the player, it refuses to start, throwing:

Code Select Expand

Can't use an undefined value as an ARRAY reference at (eval 86) line 5.

If I remove the 'if' clause (or just change $nbsongs to some independent variable), it starts and works normally, including rendering a half-sized picture when collapsed (so the actual size change must be possible). I'm using latest build from git.

So, is this just not implemented yet, or did I miss some way around the problem?

EDIT: nevermind, fixed it by setting "init_picsize". Should've looked better at the SongTree documentation before messing too much. (Though on that note: the wiki page doesn't mention that $nbsongs is available for groups, had to look into source to find it.)