#5462 closed Bugs (Fixed)

[DVDPlayer] Pressing Rewind Fast Forwards Video

Reported by: tim_wang Owned by:
Priority: 4 - Normal
Component: Video playback (inc. audio in video and codecs) Version: GIT
Severity: Normal Keywords: Rewind, DVDPlayer
Cc: elupus, AreaScout Blocked By:
Blocking: Platform: All


In XBMC 8.10 Live, pressing the rewind button fast forwards video. Instead of toggling the rewind speed between normal play, 2x, 4x, 8x, 16x, and 32x rewind, pressing the rewind button fast forwards the video until 32x rewind is reached, at which point the video actually starts to rewind.

Here is my XBMC debug log:


Attachments (8)

dvd rewind xbmc-xbmc.log (114.5 KB) - added by tim_wang at 2009-01-09T20:39:59Z.
svn17329 dvd rewind xbmc-xbmc.log (207.9 KB) - added by althekiller at 2009-01-26T15:55:31Z.
tim_wang's log from dupe ticket #5772
xbmc - Kopie.log (614.3 KB) - added by Zippolighter at 2009-12-23T12:20:34Z.
Debug Log with fast rewind (2,4,8,16,32)
xbmc.log (140.7 KB) - added by cowbalt at 2010-02-14T13:54:23Z.
same issue (log playing ISO)
rewind 2x timings log.txt (11.9 KB) - added by Voyager-xbmc at 2010-10-22T19:17:57+01:00.
Rewind modified seek-back timegraph.png (67.7 KB) - added by Voyager-xbmc at 2010-10-23T08:23:15+01:00.
time index graph with modified seekback for RW 2x
Rewind UNmodified seek-back timegraph.png (20.6 KB) - added by Voyager-xbmc at 2010-10-23T08:43:55+01:00.
For reference, comparison with current SVN code (unmodified seek back magnitude)
xbmc - ismell.log (87.2 KB) - added by ismell at 2010-11-23T02:46:21Z.

Change History (78)

comment:1 Changed at 2008-12-09T16:58:42Z by Mike Pisano

Similar problem on XBOX Reported under ticket: #5270

It's looks - "feels like" rewind is skipping back based upon a fixed size * speed (ie 1024 * 2x) where it should be taking into account file overall size of the file\VOBS or the length of the video. In the example of 1024 - that could represent 1 sec of video or 10 sec depending on compression.

For me it seems to get actual 2x Ineed 16x\32x on larger videos (4gb) where 4x\8x might work find on 2gb files which is why I make the above claim.


comment:2 Changed at 2008-12-12T23:43:18Z by sho

  • Milestone set to 9.04

Changed at 2009-01-09T20:39:59Z by tim_wang

comment:3 Changed at 2009-01-25T19:20:19Z by althekiller

  • Resolution set to Fixed in SVN
  • Status changed from new to closed

Works fine in HEAD. Either this is invalid or has already been fixed. Please test with latest code before creating a ticket in the future.

comment:4 Changed at 2009-01-26T08:17:59Z by tim_wang

I can still reproduce this bug in the following SVNs: SVN17139, SVN17292, and SVN17329 (latest SVN as of posting date.) I have resubmitted this bug under ticket #5772.

Changed at 2009-01-26T15:55:31Z by althekiller

tim_wang's log from dupe ticket #5772

comment:5 Changed at 2009-01-26T15:57:24Z by althekiller

  • Resolution Fixed in SVN deleted
  • Status changed from closed to reopened

As sho said, please don't create new tickets for existing problems. We can reopen closed tickets.

comment:6 Changed at 2009-01-26T16:07:21Z by althekiller

  • Cc elupus added

Seems to only happen with DVD/DVDISO media. Please confirm.

comment:7 Changed at 2009-01-26T16:56:32Z by Mike Pisano

For me I can confirm VOBS and XVID's on a SMB share running XBOX t3ch 12-30 release. I have gotten in the habbit of Chapter skipping backwards then fast forwarding to the spot. Would be nice to have this fixed.

comment:8 Changed at 2009-01-27T02:52:25Z by tim_wang

I tested rewind with AVI, MPEG2, and MOV video files, and it works fine with all of them. It only fast forwards with DVDs and DVD ISOs.

comment:9 Changed at 2009-02-03T11:19:33Z by sho

  • Component changed from Other (un-categorized) to Video playback (inc. audio in video)
  • Platform changed from Live to All
  • Version changed from 8.10 "Atlantis" to SVN

Forum discussion, all platforms seem affected: http://forum.xbmc.org/showthread.php?t=40161

comment:10 Changed at 2009-02-03T11:22:48Z by sho

  • Cc AreaScout added
  • Keywords DVDPlayer added
  • Summary changed from Pressing Rewind Fast Forwards Video to [DVDPlayer] Pressing Rewind Fast Forwards Video

comment:11 Changed at 2009-02-03T12:57:36Z by Mike Pisano

Just Tested with an MPEG4 and it is still choppy.

I'm going to do some further testing, but as I stated before it seems like it's worse with larger files. A 700meg file is the breaking point, Smaller files seem to work better and larger files seem worse.

I'll test a few different types and sizes and try forcing Mplayer\Dvdplayer for some more clues.

comment:12 Changed at 2009-12-10T18:07:10Z by ion_man

I can confirm this issue is still present in current svns (25484 is the last one I tested). I only experience it with DVD/VIDEO_TS and MKVs containing mpeg2 back-ups of DVDS, but not with MKVs containing h.264 video tracks.

See also this thread: http://www.xbmc.org/forum/showthread.php?t=63537

comment:13 Changed at 2009-12-23T12:19:36Z by Zippolighter

I can reproduce it in Camelot RC1 Rev25755 with 1:1 dvd ripped (VIDEO_TS), never mind wich fast rewind speed in use (2,4,8,16,32) the movie makes a fast forward. Sometimes it looks like the movie is in a loop. Attached debug log for 2 speed fast rewind, 4 speed fast rewind, 8 speed fast rewind, 16 speed fast rewind, 32 speed fast rewind from a VIDEO_TS movie.

With a mkv vc1 and h.264 movie, the fast rewind works fine.

Changed at 2009-12-23T12:20:34Z by Zippolighter

Debug Log with fast rewind (2,4,8,16,32)

comment:15 in reply to: ↑ 14 Changed at 2010-01-13T18:37:32Z by kees667

Forgot to add: link above also points to a pastebin: http://pastebin.com/m3fb909f9

comment:16 Changed at 2010-01-13T19:14:01Z by elupus

dvd's should have been fixed in svn atleast

comment:17 Changed at 2010-02-01T23:35:33Z by malloc

@elupus, is there still work to be done for other media or do you believe (but have not tested) that your fix works across the board?

comment:18 Changed at 2010-02-01T23:56:20Z by elupus

  • Milestone changed from Future / Pending to 10.05
  • Resolution set to Fixed in SVN
  • Status changed from reopened to closed

I've only fixed dvd's.. And thtat just recently actually (was a bug in previous fix). But this can be closed atleast.

comment:19 Changed at 2010-02-03T09:26:44Z by tim_wang

I can confirm that DVD rewind now works properly with svn27394. However, pressing rewind still fast forwards the video with DVD ISOs. So you might want to reopen this ticket.

comment:20 Changed at 2010-02-03T12:22:24Z by elupus

your post makes no sence.. first you say it works for dvd's then it doesn't??

comment:21 Changed at 2010-02-03T17:43:59Z by ion_man

I just tested this, rewind now works fine with mkv files that contain mpeg2 video, but VIDEO_TS folders, ISO files or DVD discs still fast forward when pressing rewind. Only 32x rewind does rewind all other speeds still fast forward instead.

So I think this ticket needs reopening.

I tested this with svn 27420.

comment:22 Changed at 2010-02-03T20:25:00Z by malloc

  • Milestone changed from 10.05 to Future / Pending
  • Resolution Fixed in SVN deleted
  • Status changed from closed to reopened

Seems to go against what elupus thinks is fixed, so reopening so he can reclose if he still believes it's fixed.

comment:23 Changed at 2010-02-04T17:45:11Z by tim_wang


What I meant was if I play a DVD movie in the DVD-ROM drive, pressing rewind will rewind the movie. However, if I play a DVD ISO from the HD, pressing rewind still fast forwards the movie. I hope this makes more sense.

comment:24 Changed at 2010-02-04T18:32:09Z by elupus

That does seem abit odd, can you post a debug log again.

Changed at 2010-02-14T13:54:23Z by cowbalt

same issue (log playing ISO)

comment:25 Changed at 2010-02-14T13:56:40Z by cowbalt

Hi elups,

I've attached the log while playing an ISO dvd file. I did a fast forward (all speeds) and fast rewind (all speeds). The movie still fastforwards when you're doing a fast rewind.

I'll try to gather a log for a VIDEO_TS folder movie as well.


comment:26 Changed at 2010-02-14T20:42:17Z by Phred2


Another log also playing an ISO.




comment:27 Changed at 2010-02-17T07:22:13Z by tim_wang

I was not able to duplicate my previous success with rewinding DVD-ROM. That previous successful test was done with a different DVD-ROM which I lost. I am now seeing the same rewind error with both DVD-ROM and DVD ISO. Here is my log from playing a DVD-ROM: http://pastebin.com/m723e188a and from playing a DVD ISO: http://pastebin.com/m2b111bfc

comment:28 Changed at 2010-02-18T20:11:42Z by Zippolighter

Rev27934 Win7 64 I make two tests with an DVD in the DVD Drive and with a 1:1 ripped DVD (VIDEO_TS Structure).

In both cases the problem is still available

comment:29 Changed at 2010-05-03T04:00:08+01:00 by go_jesse

still seeing this on xbox1 with svn 29407 from Apr-27-2010

comment:30 Changed at 2010-06-06T20:30:07+01:00 by CrystalP

I see something similar here with a DVD in the DVD drive on Win7 32. DVDPlayer seems to get stuck in a short loop when rewinding. There is no fast forward for me. Don't know about ISO images, I don't use them.

I'd like to help but I don't know where to start looking. I don't find the changesets that could have fixed it in the previous messages.

comment:31 Changed at 2010-07-07T23:44:53+01:00 by ubuntuf4n

Maybe this Ticket could help... #9000

comment:32 Changed at 2010-07-14T12:29:36+01:00 by Voyager-xbmc

I confirm the issue with both DVD ISOs and DVD VIDEO_TS files in svn31767.

It seems as if the player wants to rewind, while the inputstream keeps reading forward. Then the DVDPlayer tries to compensate in the "HandlePlaySpeed" function, it calculates an "error" between the dvd clock and the last pts. The clock thinks the movie is going backwards, but the last pts (coming from the packets in the inputstream) is always increasing. The error gets bigger and bigger. If the error > 1sec, the DVDPlayer tries to compensate by a 500ms seek backwards (which updates the pts, but insufficient to actually rewind). Only when rewinding at 32x, sometimes the compensations occur frequently enough so that it rewinds verrrry slowly (but extremely choppy).

comment:33 Changed at 2010-07-25T16:48:59+01:00 by CrystalP

elupus, pointers to fix would be appreciated. I like RW/FF, one of the reasons I chose XBMC over other apps.

comment:34 Changed at 2010-07-28T06:39:14+01:00 by Voyager-xbmc

all, I've spent hours looking at this issue in the code, and I think that the current code does not have what it takes to fix the "rewind" functionality. Since you cannot read backwards in the stream (I checked in libdvdnav and libavformat) you have to implement this by continuously doing seeks backwards (e.g. 2x rewind could be achieved by every 0.5 seconds, jump back 1 second and display 1 frame). None of this is currently coded. On the contrary, the inputstream keeps reading forward, at the absolute value of "speed" (regardless of direction).

My recommendation to devs: disable the negative speeds (Rew 2x -- 32x) for the time being and work on a decent rewind function based on consecutive seeks "backwards" as described above.

comment:35 follow-up: Changed at 2010-07-28T12:02:07+01:00 by elupus

Well there is one thing that can be done. in libdvdnav time seek function. It should take a parameter telling if it should look for the next vobunit or the previous vobunit at the given time.

Currently it does some silly interpolation, most likely causing it to always end up at the next vobunit. This could explain the issue of it fast forwarding.

comment:36 Changed at 2010-08-25T08:33:27+01:00 by Voyager-xbmc

@elupus: are you looking for some help on this, or is this a suggestion you're willing to explore and implement? @all - if it's not priority for the developers, why don't we just disable the FF/RW function & buttons (as done in VLC, Boxee, etc.) for now, until a good solution is in place?

comment:37 Changed at 2010-08-25T12:41:25+01:00 by elupus

Well the only good solution is to do it the correct way. (it's possible by reading the info in nav packets of dvds). But the best simle fix is as what i mentioned above. Not likely i'll look at it anytime soon thou.

comment:38 Changed at 2010-10-21T15:22:51+01:00 by StarChild

This is still a problem in Dharma 10.0beta3

comment:39 Changed at 2010-10-21T15:25:14+01:00 by StarChild

http://www.megaupload.com/?d=GP4I8PW0 Sample - DVD iso in a non-compressed rar archive over a smb network on a NAS

Can it be an audio sync problem?

comment:40 in reply to: ↑ 35 Changed at 2010-10-21T16:12:58+01:00 by elupus

Replying to elupus:

Well there is one thing that can be done. in libdvdnav time seek function. It should take a parameter telling if it should look for the next vobunit or the previous vobunit at the given time.

Currently it does some silly interpolation, most likely causing it to always end up at the next vobunit. This could explain the issue of it fast forwarding.

Issue is in above solution.. Ie we always look for next vobunit

comment:41 Changed at 2010-10-22T10:47:57+01:00 by Voyager-xbmc

I'm sorry, this does not make sense. I agree the Vobunit precision is an issue, but not the root cause of this problem.

I'm currently debugging the DVDPlayer/DVDPlayerVideo code - and I'm looking at the time stamps from the DVDInputStreamNavigator, and they are "quite" accurate and I would say good enough to guarantee correct rewind function.

The problem lies somewhere in the speed handling in the various player's code.

  • DVDPlayerVideo uses the "absolute" value of speed, so if you start to rewind x2 (-2000) it actually starts to speed up FF x2. This is because the time between frames gets divided by abs(m_speed): iFrameSleep = iFrameSleep * DVD_PLAYSPEED_NORMAL / abs(m_speed);
  • Because DVDPlayerVideo is speeding up, DVDPlayer is calling more frequent "readPacket" from the Demuxer, and so during a short period (I noticed this by adding extra logging in the code), DVDInputStreamNavigator is reading ahead very fast (several seconds), and then DVDPlayer realizes that it needs to correct by means of a seek (1 second back!)

The net result is FFW.

I'm doing some more investigation on how to trigger the backwards seek earlier (like after only a few frames).

comment:42 Changed at 2010-10-22T14:11:31+01:00 by cowbalt

Hey Voyager-xbmc,

Sounds like you're on track ;)

It would be good if this issue gets fixed in Dharma. I know the devs are busy doing more important things. However, in my opinion this issue excists already for a very very long time (Opened 23 months ago) and it would be good if Dharma is getting released with the least amount of bugs that are currently open.

Cheers, Cowbalt

comment:43 Changed at 2010-10-22T18:31:51+01:00 by elupus

Well i don't.

The result of the current code is that a seek is request to time 5, we end up on time 7.. The system resyncs to the current location and after half a second find out it needs to do a new seek, this time requesting time 6, we end up on time 8.. and so on.

comment:44 Changed at 2010-10-22T19:17:29+01:00 by Voyager-xbmc

agree or disagree. doesn't matter, but have a look at the attached timings log I constructed based on additional logging.

In DVDPlayer::HandlePlaySpeed, Ive added the following logs:

      error  = m_clock.GetClock() - m_SpeedState.lastpts;
      error *= m_playSpeed / abs(m_playSpeed);
      CLog::Log(LOGINFO, "*** DVDPlayer::HandlePlaySpeed - GetTime [%f] | dvdPlayerVideo CurrentPTS [%f] | clock [%f]", m_SpeedState.lasttime, m_SpeedState.lastpts, m_clock.GetClock());
      if(error > DVD_MSEC_TO_TIME(1000))
        CLog::Log(LOGDEBUG, "CDVDPlayer::Process - Seeking to catch up");
        __int64 iTime = (__int64)(m_SpeedState.lasttime + 500.0 * m_playSpeed / DVD_PLAYSPEED_NORMAL);
        CLog::Log(LOGINFO, "*** DVDPlayer::HandlePlaySpeed -                              PlayerSeek to [%d]", iTime);
        m_messenger.Put(new CDVDMsgPlayerSeek(iTime, (GetPlaySpeed() < 0), true, false, false, true));

and in DVDInputStreamNavigator the following (in ProcessBlock(), case DVD_NAV_PACKET)

        m_iTime = (int) ( m_dll.dvdnav_convert_time( &(pci->pci_gi.e_eltm) ) + m_iCellStart ) / 90;
        CLog::Log(LOGINFO, "*** DVDInputStreamNavigator::ProcessBlock case DVDNAV_NAV_PACKET : m_iTime =[%d]", m_iTime);

Now what you'll see in the txt attached below, is that pts is moving forward (as is the time index in the dvd navigator, but the clock is running backwards. The seeks are pretty accurate in their result (at most 500-700ms off) but the real problem is the massive time increase each time with all these dvd nav packets bumping up the time index...

Changed at 2010-10-22T19:17:57+01:00 by Voyager-xbmc

comment:45 Changed at 2010-10-22T19:22:00+01:00 by Voyager-xbmc

(continued) so what you can see here, is that the time index has moved forward (in playback, not due to seeks) by 8-9 seconds, before the DVDPlayer realizes the error, and decides to seek about 1 second backwards... Again, insisting on the fact that the seeks are reasonable accurate by looking at the time reported after the seek by the navigator.

comment:46 Changed at 2010-10-23T02:25:09+01:00 by elupus

I just noticed something i hadn't thought of before.. GetTime() doesn't return the clock time for dvd's as it does for normal files. That means the seek request is not done to the right point in time as expected by the rewind as it would have been for a normal file.

It's done to an offset of the last read packet from demuxer, which is utterly wrong for rewinding as that will never go back.

comment:47 Changed at 2010-10-23T08:22:33+01:00 by Voyager-xbmc

I can temporarily make the rewind work if I change the iTime calculation in the HandlePlaySpeed function as follows

__int64 iTime = (__int64)(m_SpeedState.lasttime + 2 * DVD_TIME_TO_MSEC(error) * m_playSpeed / DVD_PLAYSPEED_NORMAL);

So the time seek does work. However it's currently not big enough to compensate the read-forwards that are happening IN BETWEEN 2 seek backs. With the above modification it is, but you get the "jumpy" effect and a net slow rewind.

To illustrate, I have laid out the time indices from DVDInputStreamNavigator log in a graph (attached below)

Changed at 2010-10-23T08:23:15+01:00 by Voyager-xbmc

time index graph with modified seekback for RW 2x

Changed at 2010-10-23T08:43:55+01:00 by Voyager-xbmc

For reference, comparison with current SVN code (unmodified seek back magnitude)

comment:48 Changed at 2010-10-23T11:41:17+01:00 by elupus

Right.. (that breaks normal files thou, working on a fix) It's way harder to fix the forward frames unless we can fix so that we output keyframes from input stream backward.

comment:49 Changed at 2010-10-23T11:49:59+01:00 by elupus

Just for reference. This is possible from dvd's since they contain all info needed to accomplish that. But it's way complicated

comment:50 Changed at 2010-10-23T12:42:49+01:00 by elupus

should be fixed in trunk, give it a go and test some normal files aswell. if okey we'll backport to dharma

comment:51 Changed at 2010-10-23T12:43:01+01:00 by elupus

  • Resolution set to Fixed in SVN
  • Status changed from reopened to closed

comment:52 Changed at 2010-10-23T14:04:44+01:00 by Voyager-xbmc

fix seems to work ok. Rewind is still a bit "jumpy", but as you said earlier, fixing this by outputting the keyframes from inputstream backwards would be much harder to achieve.

comment:53 Changed at 2010-10-23T15:25:26+01:00 by cowbalt

Hey Guys,

If you could let us know when the fix is backported to Dharma, then I'll test it in a next beta release too and let you know.

Cheers, Cowbalt

comment:54 Changed at 2010-10-23T16:55:40+01:00 by malloc

Because we're so close to release, this may not be backported until it's tested in trunk. We don't want to introduce any new bugs that would hold up the release of Dharma.

comment:55 Changed at 2010-10-23T17:54:24+01:00 by cowbalt

Ok malloc. Totally understandable of course! Thanks all for your efforts so far.

comment:56 Changed at 2010-10-23T18:49:34+01:00 by StarChild

cowbalt: Why don't you download a trunk svn and test it. The more peps that test it the more chance is it that it will make it into Dharma.

comment:57 Changed at 2010-10-23T19:14:23+01:00 by cowbalt

Thanks for that StarChild :)

I'm primairy beta tester for openelec, so most likely this will happen anytime soon with a special build for me ;) I will let you guys know of course ;)

comment:58 Changed at 2010-10-26T18:19:48+01:00 by StarChild

Will test this as soon sshcs builds working again.

comment:59 Changed at 2010-10-27T01:51:06+01:00 by ronie

since you're looking for feedback... tested with .vob files, .iso files and physical dvd disks. rewind now works on all of them.

didn't see any issues with several .avi and .mkv files either.

comment:60 Changed at 2010-10-27T01:56:02+01:00 by CrystalP

Same results here, rewind works for dvds, and I didn't notice much behavior difference for other types of files.

comment:61 Changed at 2010-10-27T02:02:14+01:00 by malloc

  • Milestone changed from Future / Pending to 10.0
  • Resolution Fixed in SVN deleted
  • Status changed from closed to reopened

@elupus, good enough for backport?

comment:62 Changed at 2010-10-27T06:22:17+01:00 by Voyager-xbmc

I hate to ruin your little party, but I'm looking into two issues:

  1. when rewind reaches zero, it keeps running and should actually resume normal playback from the beginning. The effect is quite disturbing, jumping around at time index zero.
  2. With the dvd "penguins of madagascar" which is a multi episode series, rewinding does not work well as it makes huge alternating jumps forward and backwards. Perhaps something to do with negative time indices, but I need to take a closer look.

In any case, I agree that the current improvement in SVN is MUCH better than what was there before and should be backported to Dharma already.

comment:63 Changed at 2010-10-27T06:46:44+01:00 by Voyager-xbmc

edit: forget the second point, this DVD seems to be really a bad example: can't even do a regular short jump (+ or -00:30) on it.

comment:64 Changed at 2010-10-27T07:20:11+01:00 by malloc

@Voyager-xbmc, would you mind opening up new bugs for those issues? I'll let elupus decide if he cares to backport and he can reclose this bug otherwise.

comment:65 Changed at 2010-10-27T08:15:29+01:00 by Voyager-xbmc

@malloc: I agree, the problem of this ticket is resolved. What I was referring to are boundary issues that I can raise in new tickets.

comment:66 Changed at 2010-10-27T19:21:33+01:00 by elupus

  • Resolution set to Fixed in SVN
  • Status changed from reopened to closed

backported to dharma

comment:67 Changed at 2010-11-23T02:45:57Z by ismell

I'm guessing this was fixed before RC1 got released so I'll post again. I just tried the rewind on a DVD ISO and it started fast forwarding when i pushed the rewind button. I've attached the log.

Changed at 2010-11-23T02:46:21Z by ismell

comment:68 Changed at 2010-11-23T03:21:12Z by malloc

  • Resolution Fixed in SVN deleted
  • Status changed from closed to reopened

comment:69 Changed at 2010-12-15T08:23:47Z by Voyager-xbmc

@malloc: I think ismell's bug report is invalid. The debug log does not reference the rewind function (instead it is using "step back" i.e. pressing the left arrow). This has nothing to do with rewind, so we have to consider this ticket as closed again.

comment:70 Changed at 2010-12-15T08:40:14Z by malloc

  • Resolution set to Fixed in SVN
  • Status changed from reopened to closed

@ismell, please open a new trac ticket.

Note: See TracTickets for help on using tickets.