Opened 18 years ago
Closed 18 years ago
#1358 closed defect (fixed)
PVR-350: incorrect progress bar in non-LiveTV
Reported by: | anonymous | Owned by: | danielk |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | mythtv | Version: | 0.19 |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
After upgrading (using yum) to mythtv 0.19, watching recorded shows has strange behavior suggesting a discrepancy between displayed timing and internal timing:
1) commercial notifies appear too early (but this may be spurious due to bad recognition, and is not my major point) and
2) the timeline/progress bar is not in sync. This is most visible in starting to watch a show and then pressing the cursor-left (jump back) button while having the timeline visible. A jump is made, but not reflected in the timeline or time elapsed shown. Likewise, the show will continue playing after the timeline indicates it is finished, sometimes up to several minutes past 100%.
I don't think this bug is related to ticket #137 but is another problem.
Attachments (1)
Change History (14)
comment:1 Changed 18 years ago by
Version: | → 0.19 |
---|
comment:2 Changed 18 years ago by
comment:3 Changed 18 years ago by
I've also seen this on SVN head from a few days ago (9051). Also seen is that sometimes, with some recordings, trying to skip ahead over commercial breaks (I don't have automatic commercial jump switched on as it rarely seems to work as expected), the playback position will in fact jump backwards by up to 5 minutes, however the time offset does not reflect this, and in fact goes forwards.
I've not produced any logs or anything yet for this, but can do if you think there's one that will help?
comment:4 Changed 18 years ago by
Same problem here. It only happens when using the pvr-350 decoder (PAL). I have traced it down to changeset [8801].
comment:5 Changed 18 years ago by
I see this problem using Hauppage DVB receiver - at adverts on some recordings progress bar jumps to 100%. Fast forward doesnt work - pressing rewind goes back to the point where progress bar jumps.
I have recordings 2:30 long they jump at 18 minutes - normally where aspect changes occur in stream.
comment:6 Changed 18 years ago by
(I am the guy who originally reported this bug...)
I can confirm that this seems to be happening with the PVR350/PAL, as that's what I am using. I am not sure that what the parent post describes is the same bug behavior, I am not seeing any "jumping" per se while watching a recording, but only as soon as a cursor-left or cursor-right is pressed. If at all, the progress bar is lagging behind, not jumping to 100%, so the issue described above might be independent.
comment:7 Changed 18 years ago by
I have narrowed it down further, to IvtvDecoder::SetDeviceInfo?. As a test I commented out the line
devInfo[tmpStr] = tmp;
After this change the skipping is accurate. This is not a solution, just a proof of consept, since it breaks the osd (and probably a lot of other stuff).
My current workaround is to run current svn with changeset [8801] reversed. This is working fine.
comment:8 Changed 18 years ago by
Owner: | changed from Isaac Richards to danielk |
---|
comment:9 Changed 18 years ago by
Summary: | incorrect progress bar when watching recorded TV shows → PVR-350: incorrect progress bar in non-LiveTV |
---|
comment:10 Changed 18 years ago by
This is more than an incorrect progress bar - it's completely incorrect timekeeping:
- Jumping forward can take you backward
- Returning to a bookmark positions you before the bookmark
The first symptom renders commercial detection useless.
The time distortion gets progressively worse as playback continues. Jumping or returning to a bookmark resets the distortion back to zero.
This is a regression since 0.18.1. Something in changeset [8801] appears to have caused this as reverting the change against source:"/branches/release-0-19-fixes" fixes the problem on PVR350 frontends.
comment:11 Changed 18 years ago by
Changeset [8801] removed the setting of the fps member variable when !ntsc. which causes the ntsc frame rate to be used even in non-NTSC.
I've attached a simple fix.
comment:12 Changed 18 years ago by
comment:13 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
The jump back is also much longer than normal, e.g normal jump-back amount is set to 15s, but in some instances, the jump executed will be more than a minute back.