Opened 16 years ago
Closed 15 years ago
#5667 closed patch (fixed)
Commercial autoskip/notify does not always recognize beginning of commbreak
Reported by: | otto at kolsi dot fi | Owned by: | stuartm |
---|---|---|---|
Priority: | minor | Milestone: | 0.22 |
Component: | mythtv | Version: | 0.21-fixes |
Severity: | low | Keywords: | commercial break |
Cc: | Ticket locked: | no |
Description
I have some recordings that have been flagged successfully by mythcommflag. However, when playing these recordings NuppelVideoPlayer? does not recognize the beginnig of the commbreak and does not autoskip or notify the commbreak.
If the beginning of commbreak is missed but I manually jump to end of commbreak it works fine. Also if I load the skip positions to edit recordings screen, the beginnings of the commbreaks are in right positions.
If recording is fast forwarded or jumped/skipped, the problem does not occur. This slows down the debugging since I have to really play the recording from the beginning until to the problematic position.
I've added some debugging prints to NuppelVideoPlayer::AutoCommercialSkip?() and noticed that e.g. when the beginning of commbreak is at frame 41012, when that position is reached the commBreakIter has probably been incremented one time too much and it is pointing already to the beginning of the next commbreak and thus the jump/notify does not occur:
2008-09-04 22:22:40.612 NVP: DEBUG*** AutoCommercialSkip data: 4, framesPlayed: 41012, key: 71307
With this particular recording, the recording starts with a commbreak and I manually jump to the end of that commbreak when starting to watch the recording. Not sure if this step in the beginning has something to do with the problem.
I'll try to dig some more but any additional help is also appreciated.
Attachments (4)
Change History (20)
comment:1 Changed 16 years ago by
comment:2 Changed 16 years ago by
Here is the actual commflag data from the recordedmarkup table. I think in the beginning short commbreaks are merged into one commbreak, because one manual commskip gets you to frame 5800 where the actual program starts.
This brings to another question: if recording starts with a commbreak and autoskip is enabled, player still does not jump over the initial commbreak. Is this a feature or a bug?
+-------+------+ | mark | type | +-------+------+ | 0 | -3 | | 0 | 2 | | 0 | 4 | | 3648 | 5 | | 4199 | 4 | | 5800 | 5 | | 41012 | 4 | | 47958 | 5 | | 71307 | 4 | | 77449 | 5 | | 89780 | 4 | | 94432 | 5 | +-------+------+
comment:3 Changed 16 years ago by
This problem should be easy for anyone to reproduce with following steps:
- Set the merge short commbreaks setting to 0 since we will be using short breaks to demonstrate the problem.
- Enable automatic commercial skipping in settings
- Select a recording that either has not been commflagged or manually remove entries from the recordedmarkup table
- Update recorded and recordedmarkup tables so that selected recording has following commbreaks. You need to know the starttime and chanid for that recording:
insert into recordedmarkup (chanid, starttime, mark, type) values (1001, '2008-09-05 20:29:00.0', 0, 4), (1001, '2008-09-05 20:29:00.0', 5000, 5) , (1001, '2008-09-05 20:29:00.0', 10000, 4), (1001, '2008-09-05 20:29:00.0', 12000, 5); update recorded set commflagged = 1 where starttime = '2008-09-05 20:29:00.0';
- This will enable you to have commercial break right in the beginning of the recording and then another little bit later
- Start to watch the recording and in the beginning manually skip over the first commbreak (does not jump automatically, bug?)
- Then let the recording play until the beginning of the second commbreak -> automatic skip does not occur
- Re-start the recording playback and this time do not manually jump over the first commbreak -> automatic skip works as expected
Changed 16 years ago by
Attachment: | NVP_SetCommBreakIter_fix_00.diff added |
---|
comment:4 follow-up: 5 Changed 16 years ago by
Hi Otto,
Does the attached patch (NVP_SetCommBreakIter_fix_00.diff) help your situation at all?
comment:5 follow-up: 6 Changed 16 years ago by
Replying to Shane Shrybman <gnome42@gmail.com>:
Does the attached patch (NVP_SetCommBreakIter_fix_00.diff) help your situation at all?
With this patch when recording is started to watch with immediate commbreak, NVP tries to jump over it. OSD is updated with correct "Skip X:XX" info but unfortunately the actual video stream freezes and you have to kill the frontend to get out of there. Tried this with couple of recordings and it was always the same.
comment:6 follow-up: 7 Changed 16 years ago by
Perhaps a log from the frontend using 'mythfrontend -v playback,commflag' during the video freeze, might show what's going on.
Changed 16 years ago by
Attachment: | autocommskip-freeze.log added |
---|
comment:7 Changed 16 years ago by
Perhaps a log from the frontend using 'mythfrontend -v playback,commflag' during the video freeze, might show what's going on.
Frontend log attached.
Changed 16 years ago by
Attachment: | autoskip-hang-bt.txt added |
---|
comment:8 Changed 16 years ago by
Patch from Shane actually seems to work well for this problem!
In a hurry, I manually edited code wrongly (with 2 separate frontends!) and left out one line. Maybe it would be useful to learn how to apply diff "--git" patches and not do the editing by hand :)
comment:9 Changed 16 years ago by
Type: | defect → patch |
---|
comment:10 Changed 16 years ago by
Keywords: | commercial break added |
---|---|
Owner: | changed from Isaac Richards to cpinkham |
Severity: | medium → low |
Status: | new → assigned |
This patch resolves the problem of not being able to skip the first commercial break if the break starts at the beginning of the recording.
It has been tested by Otto and myself on 0.21-fixes but likely applies to trunk as well.
comment:11 Changed 16 years ago by
I have been using this with trunk for the last couple of days. Seems to fix the problem nicely.
comment:12 Changed 15 years ago by
I have been using this on 21-fixes for about a week now and it does fix the problem for me.
comment:13 Changed 15 years ago by
Owner: | changed from cpinkham to stuartm |
---|
comment:14 Changed 15 years ago by
Milestone: | unknown → 0.22 |
---|---|
Status: | assigned → started |
comment:15 Changed 15 years ago by
Changed 15 years ago by
Attachment: | NVP_SetCommBreakIter_fix_01.diff added |
---|
Updated patch for trunk r19512
comment:16 Changed 15 years ago by
Resolution: | → fixed |
---|---|
Status: | started → closed |
Problem indeed has something to do with the manual commercial skip in the beginning of the recording. When this particular recording is watched from the beginning without the manual commskip, it works well.
Following shows which kind of commbreak list there is available for this recording:
Could it be related to the non-even number of commbreaks in the beginning?