[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#287871: marked as done (seek forward can start from wrong offset when new song is chosen)



Your message dated Thu, 28 Nov 2019 06:35:41 +0000
with message-id <E1iaDOv-000FIh-5x@fasolo.debian.org>
and subject line Bug#827890: Removed package(s) from unstable
has caused the Debian Bug report #287871,
regarding seek forward can start from wrong offset when new song is chosen
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
287871: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287871
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: cplay
Version: 1.49-6
Severity: minor

Image that you play a song, then you either select the next song (with
n) or start the same song again (with enter), and then you immediately
press ctrl-f to forward in the new song.  In most cases, cplay does
the right thing and starts the forward from offset 0 in the new file.
However, in some cases it starts from the offset of the last song
which was played.

This is a bit tricky to reproduce since you have to be very quick and
need some luck, but I added some debug messages to cplay to show
what's going on.  Basically, what happens is that the new song is
chosen, offset is set to 0, but then sometimes parse_progress() would
be called which still has the file handles of the old song.  It will
parse the output and set offset to the old offset, overwriting
offset = 0 which was just set.

I guess cplay should immediately close the file handles when a new
song is chosen to make sure that the output of the old song is not
parsed.

Here is the case when a new song was chosen, ctrl-f pressed
immediately and it would continue from the old offset.  The
interesting line is "Player set_position(): offset = 3039..." right
after the offset is set to 0:

[the old song plays at some offset]
Player set_position(): offset = 3037, length  = 7197, values = [3037, 4160]
Player parse_progress(): self.stopped: 0, self.step: 0
Player set_position(): offset = 3039, length  = 7198, values = [3039, 4159]
[a new song is chosen, offset set to 0, etc]
command_play()
command_play(): entry exists (1)
command_play(): entry exists (2)
Applicaton play(): offset = 0
Player stop():
Player setup(): offset: 0
Player setup(): offset is 0, setting self.offset = 0
Applicaton play(): ok, found player: offset = 0
play(): self.offset : 0
play(): self.offset : 0
update_status()
Player parse_progress(): self.stopped: 0, self.step: 0
[the output of the old song are read and offset is overwritten]
Player set_position(): offset = 3039, length  = 7197, values = [3039, 4158]
Applicaton(): offset = 1, relative = 1
Player(): offset = 1, relative = 1
 self.length: 7197
 self.offset: 3039
 self.step (before): 0.000000
 self.step (after): 14.394000
 self.offset (before): 3039.000000
 self.offset (after): 3053.394000
play(): self.offset : 0
Applicaton(): offset = 1, relative = 1
Player(): offset = 1, relative = 1
 self.length: 7197
 self.offset: 3053
 self.step (before): 14.394000
 self.step (after): 28.788000
 self.offset (before): 3053.394000
 self.offset (after): 3082.182000
Applicaton(): offset = 1, relative = 1
Player(): offset = 1, relative = 1
 self.length: 7197
 self.offset: 3082
 self.step (before): 28.788000
 self.step (after): 43.182000
 self.offset (before): 3082.182000
 self.offset (after): 3125.364000


In comparison, this is what happens normally:

Player set_position(): offset = 2356, length  = 7196, values = [2356, 4840]
Player parse_progress(): self.stopped: 0, self.step: 0
Player set_position(): offset = 2357, length  = 7196, values = [2357, 4839]
command_play()
command_play(): entry exists (1)
command_play(): entry exists (2)
Applicaton play(): offset = 0
Player stop():
Player setup(): offset: 0
Player setup(): offset is 0, setting self.offset = 0
Applicaton play(): ok, found player: offset = 0
play(): self.offset : 0
play(): self.offset : 0
play(): self.offset : 0
update_status()
Player parse_progress(): self.stopped: 0, self.step: 0
Player set_position(): offset = 0, length  = 7196, values = [0, 7196]
Applicaton(): offset = 1, relative = 1
Player(): offset = 1, relative = 1
 self.length: 7196
 self.offset: 0
 self.step (before): 0.000000
 self.step (after): 14.392000
 self.offset (before): 0.000000
 self.offset (after): 14.392000
Applicaton(): offset = 1, relative = 1
Player(): offset = 1, relative = 1
 self.length: 7196
 self.offset: 14
 self.step (before): 14.392000
 self.step (after): 28.784000
 self.offset (before): 14.392000
 self.offset (after): 43.176000
Applicaton(): offset = 1, relative = 1
Player(): offset = 1, relative = 1
 self.length: 7196
 self.offset: 43
 self.step (before): 28.784000
 self.step (after): 43.176000
 self.offset (before): 43.176000
 self.offset (after): 86.352000
Applicaton(): offset = 1, relative = 1



-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages cplay depends on:
ii  python                        2.3.4-5    An interactive high-level object-o

-- no debconf information

-- 
Martin Michlmayr
http://www.cyrius.com/


--- End Message ---
--- Begin Message ---
Version: 1.50-2+rm

Dear submitter,

as the package cplay has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/827890

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

--- End Message ---

Reply to: