Ubunru 16.04. LTS, get 2.6-alpha1 from from sources
Don't work right from console, when i write something like: mocp -f; mocp -Q '%file', terminal dont show next (current after mocp -f) file.
Works fine here with Debian's moc-2.6.0~svn-r2848-1 which should be available in Ubuntu as well. I testet on the Linux Console, which I do prefer, and in an urxvt terminal.
For me the behaviour is random. Sometimes it shows the old song, sometimes the new one. I guess MOC needs a bit of time to process "next" request and a race condition occurs.
The server takes a little time to switch to the next track and it may not make it in time to satisfy the information request. Whether or not it makes it depends on how much audio is currently buffered by the hardware, which sound subsystem you are using, how many cores your machine has, how fast it is, how much CPU and I/O contention there is, how fast your HDDs are, whether or not your audios are on a network device, whether or not the next audio has tags which need to be processed and whether or not those tags are already in the tags cache.
Maybe this would give more consistant results:
mocp -f; sleep 1; mocp -Q '%file'
If your configuration introduces more than a one second delay you may have to increase the value of sleep.
riesebie
Mon, 2016-10-10 18:30
Permalink
Works fine here with Debian's
Works fine here with Debian's moc-2.6.0~svn-r2848-1 which should be available in Ubuntu as well. I testet on the Linux Console, which I do prefer, and in an urxvt terminal.
Elimar
tomaszg
Mon, 2016-10-10 18:35
Permalink
For me the behaviour is
For me the behaviour is random. Sometimes it shows the old song, sometimes the new one. I guess MOC needs a bit of time to process "next" request and a race condition occurs.
jcf
Mon, 2016-10-10 19:41
Permalink
Good Things Take Time
Yeah, it's a race condition.
The server takes a little time to switch to the next track and it may not make it in time to satisfy the information request. Whether or not it makes it depends on how much audio is currently buffered by the hardware, which sound subsystem you are using, how many cores your machine has, how fast it is, how much CPU and I/O contention there is, how fast your HDDs are, whether or not your audios are on a network device, whether or not the next audio has tags which need to be processed and whether or not those tags are already in the tags cache.
Maybe this would give more consistant results:
mocp -f; sleep 1; mocp -Q '%file'If your configuration introduces more than a one second delay you may have to increase the value of
sleep.