The code that currently implements playback-seek-relative is this, from
audtool_handlers_playback.c, lines 138-142:
oldtime = audacious_remote_get_output_time(dbus_proxy);
diff = atoi(argv[1]) * 1000;
newtime = oldtime + diff;
audacious_remote_jump_to_time(dbus_proxy, newtime);
The first problem with this code is what this bug report is concerned
with: audtool pays no attention to whether the calculated "newtime" is
within the current song or even non-negative, for that matter. So it
passes invalid times to audacious_remote_jump_to_time, which silently
fails.
The second problem is the race condition produced by calculating
"newtime" right in the audtool process while Audacious itself continues
merrily on. An example:
1. Audacious is playing a 3-minute song, and is a fraction of a second
from the end of the song.
2. audtool calls audacious_remote_get_output_time and gets something
like 2.59.98.
3. Audacious comes to the end of the song and goes on to the next one,
so the time is now, let's say, 0.00.01.
4. audtool was told to seek ten seconds backwards, so it calculates
"newtime" as 2.49.98. It passes this number through
audacious_remote_jump_to_time.
5. Audacious obligingly seeks to 2.49.98 -- in the new song. So it has
just skipped about 3 minutes of music when the user only wanted to play
the last ten seconds over again.
Basically, a relative seek function would have to be implemented within
the main Audacious process to work correctly, probably right in the
decoder loop of each input plugin. This would be possible to do, but I
question whether it's worth this much effort just to provide a function
in audtool that's not even in Audacious itself. I suggest that
"playback-seek-relative" should simply be dropped.
John
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
