Ticket #1660 (new defect)

Opened 3 months ago

Last modified 3 months ago

HTTP: seeking backward does not update position

Reported by: rocket888 Assigned to:
Priority: low Milestone: Bugs paradize
Component: HTTP Interface Version: master
Severity: minor Keywords:
Cc: Platform(s): all
Difficulty: unknown Work status: Not started

Description

I'm running both the standard gui interface and an http interface (on xp home sp2). I send in remote commands to seek and in almost all cases the the current play time is not updated (i.e. one in about 10 times it works as expected). However, the seek did work and the video is ok too, it's just the info on the current play position which is wrong.

Here's how I seek 30 seconds (this does do the seek, and the slider moves too, but the info returned is wrong and the gui position status is stuck)

http://localhost:8080/requests/status.xml?command=seek&val=%2B30s

The slider moves but the status bar time doesn't change. In addition, reading back the output from

http://localhost:8080/requests/status.xml

shows the value for the time to be unchanged (i.e. its stuck).

If I touch the slider in the gui (just left mouse click on it without dragging it which does not alter its postion) it works again until the next time I send in a seek.

Once in a while it does not stick. I'm playing an mpg 2 file.

Change History

03/07/08 18:13:51 changed by courmisch

  • platform changed from Win32 to all.
  • version changed from 0.8.6 (bugfix) to master.
  • summary changed from position info not updated after http seek to HTTP: seeking backward does not update position.

08/07/08 02:05:46 changed by rocket888

I'm pretty sure that this problem happens regardless of the direction of seek. I also have noticed that sometimes after a while (like 10-20 seconds) it will begin to update again. When it works, it does seem to work better at forward seeking, but nothing is 100% repeatable. Likely some sort of race condition - but that's just a novice guess.

25/07/08 06:52:12 changed by rocket888

Significant data point,

When these mpeg2 files are converted to dvd format, e.g. using video redo, or AVS video converter, the result is near perfect, at least in this user's experience. Not only does this seek correctly, but I'm experincing no significant delays, even over my wireless to the laptop.

Is this still worth fixing? I think so. This data point should simplify finding what's wrong, plus there was a mention on the boards that this behavior is a new phenomenon, since a few versions back.