Mailing List Archive

On Friday 09 May 2003 01:54 am, Craig Longman wrote:
> i'd like some help confirming/refuting one of the problems i'm seeing
> with mythtv. when i record a show in the background and watch it later,
> the commercial skipping works quite nicely and is very fast. however,
> if i've watched the show 'live' while its being recorded, then the
> commercial skip sucks, taking 10s of seconds to skip through minutes of
> video. at least, i'm getting reasonably confident that watching it live
> causes the commercial skipping to suck, but i'd like someone else to get
> similar results before i presume thats the issue.
>
> anyone else notice this?

With hardware encoding, it can't pre-process the video and look for
commercials while it records. So in live tv mode, it has to decode every
frame when you tell it to skip the commercial. Quite naturally, this takes a
bit of time, as you've seen.

Isaac

What you are seeing is normal. The commercial detection takes a large
amount of grunt to determine blank frames, so after a recording has finished
a background process does all the hard work and saves it to a cut list, so
during playback it is almost instant. When you hit Z during live TV it is
actually doing all the hard work straight away hence the slowness..

Cheers
Peter

-----Original Message-----
From: mythtv-users-bounces@snowman.net
[mailto:mythtv-users-bounces@snowman.net]On Behalf Of Craig Longman
Sent: Friday, 9 May 2003 1:55 PM
To: mythtv-users
Subject: [mythtv-users] commercial skipping recorded shows


i'd like some help confirming/refuting one of the problems i'm seeing
with mythtv. when i record a show in the background and watch it later,
the commercial skipping works quite nicely and is very fast. however,
if i've watched the show 'live' while its being recorded, then the
commercial skip sucks, taking 10s of seconds to skip through minutes of
video. at least, i'm getting reasonably confident that watching it live
causes the commercial skipping to suck, but i'd like someone else to get
similar results before i presume thats the issue.

anyone else notice this?

cheers,

CraigL->Thx()'


_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

On Thursday, May 8, 2003, at 10:54 PM, Craig Longman wrote:

>
> i'd like some help confirming/refuting one of the problems i'm seeing
> with mythtv. when i record a show in the background and watch it
> later, the commercial skipping works quite nicely and is very fast.
> however, if i've watched the show 'live' while its being recorded,
> then the commercial skip sucks, taking 10s of seconds to skip through
> minutes of video. at least, i'm getting reasonably confident that
> watching it live causes the commercial skipping to suck, but i'd like
> someone else to get similar results before i presume thats the issue.
>

My understanding:
When a show is finished recording (as in your "background" scenario)
mythtv then processes the file, then marks commercials. So when you hit
"commercial skip" it already knows where the commercials are and jumps
right to the correct spot. When you hit "commercial skip" on a file
that isn't finished recording yet, you force the commercial detection
code to run "on demand" rather than when the recording is complete. Add
in the fact that it can only use spare cpu for the process since it
still has to be recording, and you can imagine it takes a little time.
Personally I don't use commercial skip with live tv, as I notice it
induces some stuttering in the in progress recording.


best,
Cedar

Isaac Richards wrote:

>On Friday 09 May 2003 01:54 am, Craig Longman wrote:
>
>
>>i'd like some help confirming/refuting one of the problems i'm seeing
>>with mythtv. when i record a show in the background and watch it later,
>>the commercial skipping works quite nicely and is very fast. however,
>>if i've watched the show 'live' while its being recorded, then the
>>commercial skip sucks, taking 10s of seconds to skip through minutes of
>>video. at least, i'm getting reasonably confident that watching it live
>>causes the commercial skipping to suck, but i'd like someone else to get
>>similar results before i presume thats the issue.
>>
>>anyone else notice this?
>>
>>
>
>With hardware encoding, it can't pre-process the video and look for
>commercials while it records. So in live tv mode, it has to decode every
>frame when you tell it to skip the commercial. Quite naturally, this takes a
>bit of time, as you've seen.
>
so the answer (right now at least) is if you hope to be able to skip
around a recorded show with any reasonable speed, then don't watch it
while its recording? is this also true if i come in after its started
and watch the show 10 seconds behind 'live', will the commecial skipping
work on recorded the file then?

please note, i'm not talking about skipping around commercials in live
tv, or while watching almost live tv. i'm taking about watching a show
as it is being recorded (via a schedule). then going back to 'play
recordings' and watching it again, not live. however, shows that i
haven't watched while recording skip quite quickly.

this isn't (as i tried to point out in the original post) the actual
'live-tv' skipping i'm talking about. i'm not sure if that makes a
difference, but your post issac seems to be referring to the actual
live-tv mode.

cheers,

CraigL->Thx();

>> On Friday 09 May 2003 01:54 am, Craig Longman wrote:
>>
>>
>>> i'd like some help confirming/refuting one of the problems i'm seeing
>>> with mythtv. when i record a show in the background and watch it later,
>>> the commercial skipping works quite nicely and is very fast. however,
>>> if i've watched the show 'live' while its being recorded, then the
>>> commercial skip sucks, taking 10s of seconds to skip through minutes of
>>> video. at least, i'm getting reasonably confident that watching it live
>>> causes the commercial skipping to suck, but i'd like someone else to get
>>> similar results before i presume thats the issue.
>>>
>>> anyone else notice this?

Yes but it isn't watching it that causes it to suck, it's
the lack of something that isn't added until the end.

> Isaac Richards wrote:
>> With hardware encoding, it can't pre-process the video and look for
>> commercials while it records. So in live tv mode, it has to decode
>> every frame when you tell it to skip the commercial. Quite naturally,
>> this takes a bit of time, as you've seen.
>>
> so the answer (right now at least) is if you hope to be able to skip
> around a recorded show with any reasonable speed, then don't watch it
> while its recording? is this also true if i come in after its started
> and watch the show 10 seconds behind 'live', will the commecial skipping
> work on recorded the file then?

While Isaac is correct about decoding hardware encoding,
what you describe is consistent with the lack of a "seektable".
This is used for rapid navigation around the file but is
appended to the end of the file when the recording finishes.
Until the seektable is written, playback needs to search
through the file without this road map.

So, if you record a show from 8:00 until 9:00 and start watching
it at 8:30, any seeks (commercial skips, ff/rew, jumps, etc.)
will all be slow and commercial skips on a remote frontend are
no fun at all. You can't Save Position even if it says so on
screen and edit mode doesn't even try to pretend it might work.

However, if you exit playback at 9:01 then start watching it
again, all these features work correctly and your commercial
skips will be instantaneous.

So it's not the fact that you are watching the recording in
progress that's slowing things down, it's the fact that the
recording hasn't finished.

-- bjm

On Friday 09 May 2003 06:49 am, Bruce Markey wrote:
> While Isaac is correct about decoding hardware encoding,
> what you describe is consistent with the lack of a "seektable".
> This is used for rapid navigation around the file but is
> appended to the end of the file when the recording finishes.
> Until the seektable is written, playback needs to search
> through the file without this road map.
>
> So, if you record a show from 8:00 until 9:00 and start watching
> it at 8:30, any seeks (commercial skips, ff/rew, jumps, etc.)
> will all be slow and commercial skips on a remote frontend are
> no fun at all. You can't Save Position even if it says so on
> screen and edit mode doesn't even try to pretend it might work.
>
> However, if you exit playback at 9:01 then start watching it
> again, all these features work correctly and your commercial
> skips will be instantaneous.
>
> So it's not the fact that you are watching the recording in
> progress that's slowing things down, it's the fact that the
> recording hasn't finished.

That's pretty much completely false. The recorder (with both software and
hardware encoding) builds the seek table as the program is being recorded
(and with live tv). The player, if requested to seek to a portion of the
program it hasn't seen itself yet simply queries the recorder for the proper
position to seek to. It's only slightly slower than seeking around after the
recording has finished.

Isaac

> >>> if i've watched the show 'live' while its being recorded, then the
> >>> commercial skip sucks, taking 10s of seconds to skip through minutes of
>

<snip>

> what you describe is consistent with the lack of a "seektable".

<snip again>

> So it's not the fact that you are watching the recording in
> progress that's slowing things down, it's the fact that the
> recording hasn't finished.

Isaac already responded to this, but I wanted to throw in my $0.02 as
well. Since the seektable is available to the frontend while watching
LiveTV or an in-progress recording, then seeks can happen very fast.

The slowdown occurs when you try to use the commercial skip feature
before a recording is finished since the commercial skip information is
not saved to the database until the recording completes. During recording,
blank frames are detected and a list is kept. That list gets saved to
the database immediately after the recording finishes so if you start
watching right away you can get fairly accurate commercial skips based
upon just the blank frames. Then another thread is fired off which
plays back through the recorded video and does the commercial detection.
Currently the only method used for detection is blank-frame, so the
commercial skip list generated by the FlagCommercials thread should
be equivalent to the skip list that is generated on-the-fly by the player
if a blank frame list exists but no commercial skip list exists. I am
currently tossing around a few ideas on what to proceed with next to
add some better/additional detection methods to the FlagCommercials
thread, so that will get better as time goes by.

The blank frame list that is saved by the recorder is used to allow
the player to do some fairly accurate commercial skipping before the
actual commercial skip list is generated by the post-processing
FlagCommercials thread.

If no blank frame list or commercial skip list exists for a video,
then the player has to manually scan frame-by-frame to find blank frames.
This is SLOWWWWWWWWWW and is the pause that is being seen. I believe
that I can eliminate this by adding code to allow the frontend to query
the current blank frame list from the recorder the same way it queries
the seektable. This blank frame list could then be used to generate
a quick commercial skip list to allow nearly instantaneous skipping.

It's on my TODO list which means it's running as a nice-ed background
process in my brain right now. :) This should be pretty easy to do, so
it should be implemented in the near future.

Chris

ok, i think everyone is missing the point here, let me try and outline
the steps more clearly.

show a)

records from 1700-1800h. i'm away at the time so i can't watch it while
its recording. at 1830h i come in to watch it, i skip commercials and
everything is cool.

show b)

records from 2000-2100. i'm home while this is recording, so i decide
to watch it. i watch it and like it very much, so at 2130h, i decide i
want to watch it again. now, when i skip commercials, its unbearably
slow, with lots of disk activity, like there is no seektable.

none of my problems deal with the live tv directly, ONLY with watching a
recorded show long after its done recording.

the more i listen to what people are saying about this, the more i'm
sure what i'm seeing here is a real bug, but i'm also pretty sure some
that no-one is understanding what i mean. i hope this clears it up.

cheers,

CraigL->Thx();

> If no blank frame list or commercial skip list exists for a video,
> then the player has to manually scan frame-by-frame to find blank
frames.
> This is SLOWWWWWWWWWW and is the pause that is being seen. I believe
> that I can eliminate this by adding code to allow the frontend to query
> the current blank frame list from the recorder the same way it queries
> the seektable. This blank frame list could then be used to generate
> a quick commercial skip list to allow nearly instantaneous skipping.

It could easily be me, but I recently switched my box over to do
transcoding, and (to me) it seems like commercial skips are slow now.
This is hours later after the show has been transcoded--I just seem to
remember hitting skip and instantly being at the next breakpoint. Now, it
seems like I'll hit it, it'll immediately (in the OSD) show 'Skipping xxx
seconds' (indicating to me that there is a blank frame list in the
database), but then it'll hang there for about 5-10 seconds before jumping
to the breakpoint.

I apoligize if it's completely my imagination, but I've taken to hitting
forward several times as the commercial skip takes way too long for me
anymore--I used to love it in the past, though, because it was an
instantaneous jump.

> It's on my TODO list which means it's running as a nice-ed background
> process in my brain right now. :) This should be pretty easy to do, so
> it should be implemented in the near future.

The mythtranscode process fires off as a nice'd background process, so
borrowing that code should be easy enough to do :) Perhaps even splitting
it out (like mythtranscode) so that it can be scheduled--meaning,
commercial-detect is fired off first, then transcode? That could also
allow commercial-detect to restart on unfinished jobs if the backend goes
down in the middle of a detection, like transcode does.

Craig Longman wrote:

> records from 2000-2100. i'm home while this is recording, so i decide
> to watch it. i watch it and like it very much, so at 2130h, i decide
> i want to watch it again. now, when i skip commercials, its
> unbearably slow, with lots of disk activity, like there is no seektable.

I think I see that as well. I have some (long ago recorded) recording,
in which fastforward is terribly slow, about 2-3 times as fast as
playback, skipping 10 mins forward takes several minutes. Bookmarks
(saving positions) don't work either.

And I have one which doesn't want to play at all anymore - it used to,
but quickly went totally out of sync. Now, when I try to step into it,
the player does nothing (not even a "state none to watchingprerecorded"
on the console), and the backend has 100% CPU seemingly forever (30
minutes and more? for a 1 hour programme). Running it in gdb and
aborting it shows that it's somewhere stuck in threading code
(wait-something, no mythtv code in the bt at all). I tried using the
code (both backend and frontend) from before the ringbuffer changes, but
that crashes immediately.

I think with all of them, I shortly looked into the in-process recording
back then, to check that the recording is working correctly.

Isaac Richards wrote:
> On Friday 09 May 2003 06:49 am, Bruce Markey wrote:
>
>>While Isaac is correct about decoding hardware encoding,
>>what you describe is consistent with the lack of a "seektable".
>>This is used for rapid navigation around the file but is
>>appended to the end of the file when the recording finishes.
>>Until the seektable is written, playback needs to search
>>through the file without this road map.
>>
>>So, if you record a show from 8:00 until 9:00 and start watching
>>it at 8:30, any seeks (commercial skips, ff/rew, jumps, etc.)
>>will all be slow and commercial skips on a remote frontend are
>>no fun at all. You can't Save Position even if it says so on
>>screen and edit mode doesn't even try to pretend it might work.
>>
>>However, if you exit playback at 9:01 then start watching it
>>again, all these features work correctly and your commercial
>>skips will be instantaneous.
>>
>>So it's not the fact that you are watching the recording in
>>progress that's slowing things down, it's the fact that the
>>recording hasn't finished.
>
>
> That's pretty much completely false.

A-ha! Not completely false ;-). I apologize If I misrepresented
the specific causes and effects but each of the things I mentioned
are adversely affected by the lack of a seektable when watching
a recording in progress rather than watching a recording after
it has finished and the seektable has been written.

Edit mode is disable if haspositionmap is false. If I go into
a recording in progress or a file leftover from the backend
crash, there is no edit mode. After a file finishes correctly
the edit mode works.

Save position during a recording in progress does write a value
into "bookmark" in the recorded table. However, if I exit and
restart playback while the recording is in progress, playback
starts from the beginning. If I wait until the recording finishes
then restart playback, it starts from the bookmark position.

Seeking from a remote frontend can be conspicuously slower
during a recording in progress. The longer the seek, the
longer the wait. After the seek table has been written, seeks
of any distance are reasonably quick.

> ... The recorder (with both software and
> hardware encoding) builds the seek table as the program is being recorded
> (and with live tv). The player, if requested to seek to a portion of the
> program it hasn't seen itself yet simply queries the recorder for the proper
> position to seek to. It's only slightly slower than seeking around after the
> recording has finished.

The problem is that the sequential requests for each keyframe
can be painfully slow. To demonstrate, I started a recording
on a backend across a 10Mb network and printed the transactions
with time stamps. I waited until it had recorded for more than
ten minutes so I cound time a ten minute jump.

[Hit "Page Up" to jump forward 10 minutes]
14:55:27 50 QUERY_FILETRANSFER 21[]:[]REQUEST_BLOCK[]:[]128000
14:55:27 50 QUERY_FILETRANSFER 21[]:[]REQUEST_BLOCK[]:[]128000
14:55:27 39 QUERY_RECORDER 1[]:[]GET_FRAMES_WRITTEN
14:55:28 50 QUERY_FILETRANSFER 21[]:[]REQUEST_BLOCK[]:[]128000
14:55:28 39 QUERY_RECORDER 1[]:[]GET_FRAMES_WRITTEN
14:55:28 49 QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]6
14:55:28 49 QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]7
14:55:28 49 QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]8
...(36 seconds later)...
14:56:04 51 QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]603
14:56:04 51 QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]604
14:56:05 51 QUERY_RECORDER 1[]:[]GET_KEYFRAME_POS[]:[]0[]:[]605
14:56:05 31 QUERY_FILETRANSFER 21[]:[]PAUSE
14:56:05 74 QUERY_FILETRANSFER 21[]:[]SEEK[]:[]0[]:[]202468455[]:[]1[]:[]0[]:[]2436550
14:56:05 50 QUERY_FILETRANSFER 21[]:[]REQUEST_BLOCK[]:[]128000
14:56:05 50 QUERY_FILETRANSFER 21[]:[]REQUEST_BLOCK[]:[]128000

The same 10 minute jump from the beginning when starting playback
two minutes after the the show finished recording.

[Hit "Page Up" to jump forward 10 minutes]
15:02:54 50 QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]128000
15:02:55 50 QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]128000
15:02:55 50 QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]128000
15:02:56 31 QUERY_FILETRANSFER 17[]:[]PAUSE
15:02:56 74 QUERY_FILETRANSFER 17[]:[]SEEK[]:[]0[]:[]202433477[]:[]1[]:[]0[]:[]2813748
15:02:56 48 QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]2048
15:02:56 50 QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]128000
15:02:56 50 QUERY_FILETRANSFER 17[]:[]REQUEST_BLOCK[]:[]128000


I'm sure you'll agree that 37 seconds vs. less than 2 seconds is
more than "only slightly slower" =). However, this could probably
be improved. It looks like NuppelDecoder::DoFastForward() has a
loop requesting GetKeyframePosition(i) to fill in the position
map one item at a time. Therefore, the RemoteEncoder function
requests these one at a time. Perhaps a function could request
an array of keyframes. DoFastForward already knows the range
of numbers it needs so maybe they could all be sent in a single
network transaction. Then it would be only slightly slower.

-- bjm

Chris Pinkham wrote:
>>>>>if i've watched the show 'live' while its being recorded, then the
>>>>>commercial skip sucks, taking 10s of seconds to skip through minutes of
>>
>
> <snip>
>
>>what you describe is consistent with the lack of a "seektable".
>
>
> <snip again>
>
>>So it's not the fact that you are watching the recording in
>>progress that's slowing things down, it's the fact that the
>>recording hasn't finished.
>
>
> Isaac already responded to this, but I wanted to throw in my $0.02 as
> well. Since the seektable is available to the frontend while watching
> LiveTV or an in-progress recording, then seeks can happen very fast.

And I responded to Isaac that requesting position information
can be very slow compared to reading in the seektable at the
beginning of playback and some feature are turned off if there
is no seektable in the file.

> The slowdown occurs when you try to use the commercial skip feature
> before a recording is finished since the commercial skip information is
> not saved to the database until the recording completes. During recording,
> blank frames are detected and a list is kept. That list gets saved to
> the database immediately after the recording finishes so if you start
> watching right away you can get fairly accurate commercial skips based
> upon just the blank frames.

Didn't it originally write recordedmarkup entries as blanks
were found? I remember that this was a clue that two backends
were recording the same show because the database was throwing
errors whenever it got a duplicate for the same frame in the
same show.

> Then another thread is fired off which
> plays back through the recorded video and does the commercial detection.
> Currently the only method used for detection is blank-frame, so the
> commercial skip list generated by the FlagCommercials thread should
> be equivalent to the skip list that is generated on-the-fly by the player
> if a blank frame list exists but no commercial skip list exists. I am
> currently tossing around a few ideas on what to proceed with next to
> add some better/additional detection methods to the FlagCommercials
> thread, so that will get better as time goes by.
>
> The blank frame list that is saved by the recorder is used to allow
> the player to do some fairly accurate commercial skipping before the
> actual commercial skip list is generated by the post-processing
> FlagCommercials thread.
>
> If no blank frame list or commercial skip list exists for a video,
> then the player has to manually scan frame-by-frame to find blank frames.

But you have been finding the blank frames so it shouldn't need
to rescan....

> This is SLOWWWWWWWWWW and is the pause that is being seen. I believe
> that I can eliminate this by adding code to allow the frontend to query
> the current blank frame list from the recorder the same way it queries
> the seektable. This blank frame list could then be used to generate
> a quick commercial skip list to allow nearly instantaneous skipping.

Exactly. The rescan is rediscovering a list of frame numbers
that appear to be blank. If you already have that list in
memory or the recordedmarkup table that list should be used
when running the code to find the commercial skips. The
exception, of course, is hardware encoding when you don't
mark blanks while recording.

> It's on my TODO list which means it's running as a nice-ed background
> process in my brain right now. :) This should be pretty easy to do, so
> it should be implemented in the near future.

Best wishes. I think this would be a nice improvement.

Chris, I'd been meaning to ask you about something. When
"Automatically Flag Commercials" first appeared, I set this
thinking it was a good thing. However, a backend thread would
be busy for maybe a half hour after a recording finished.
When I looked into it, it appeared that blanks were correctly
being marked during software encoding. However, with Flag
Commercials set, at the end of recording it would delete all
recordedmarkup entries for that show then start re-reading
the file from the beginning to mark (the same ;-) blank
frames over again.

Is this feature intended to mark blanks for hardware encoded
files? If I turn this feature off, commercial skips work just
fine for files that have finished recording. If it is just
for hardware encoded files, maybe the Setup help text should
explain that. Also, maybe if when it starts it could check to
see if there are entries for that show in recordedmarkup and
decide that re-reading the file is unnecessary. I suspect
this would be useful for people using combinations of ivtv
and bttv cards or Matrox and bttv cards.

-- bjm

> Didn't it originally write recordedmarkup entries as blanks
> were found? I remember that this was a clue that two backends
> were recording the same show because the database was throwing
> errors whenever it got a duplicate for the same frame in the
> same show.

The recording process has never written the blank frame map to the
database, it has always happened in tv_rec.cpp after the recording
finished. I've modified the recorder and player in my cvs copy so
that the player writes the blank frame list every X blank frames to
the database (still tuning what X should be). I've also modified the
player so that if you're watching LiveTV it will try to get the latest
blank frame list from the DB and build a quick commercial skip list from
that before trying to skip. This should eliminate having to search for
blank frames manually for people doing software encoding.

> But you have been finding the blank frames so it shouldn't need
> to rescan....

It doesn't really for people using software encoding, but since blank frame
detection isn't 100% perfect and since I plan on implementing other
detection methods to try to get closer to that 100%, then this post-recording
scan framework was put in place. I could make it short-circuit and skip
the post-recording scan if you're using software encoding, but then you
wouldn't benefit from the other detection methods as they are added. I'm
looking at incorporating some form of scene change detection right now.

> Chris, I'd been meaning to ask you about something. When
> "Automatically Flag Commercials" first appeared, I set this
> thinking it was a good thing. However, a backend thread would
> be busy for maybe a half hour after a recording finished.
> When I looked into it, it appeared that blanks were correctly
> being marked during software encoding. However, with Flag
> Commercials set, at the end of recording it would delete all
> recordedmarkup entries for that show then start re-reading
> the file from the beginning to mark (the same ;-) blank
> frames over again.

Little-known secret. With the current code, since the only detection method
being used is blank-frame detection, you should be able to turn off the
auto-flagging setup option and still be able to skip commercials quickly,
so you are correct. If you are happy with the accuracy of that, then feel
free to turn the auto-flagging off, but when we start adding better detection
methods that can't be done real-time while recording, then you wouldn't benefit
unless you turned auto-flagging back on at that time.

Auto-flagging is REQUIRED for the commercial detection code to work for
people with hardware encoders though, that is another reason not to recommend
turning this setting off.

Chris

On Friday 09 May 2003 08:19 pm, Bruce Markey wrote:
> I'm sure you'll agree that 37 seconds vs. less than 2 seconds is
> more than "only slightly slower" =). However, this could probably
> be improved. It looks like NuppelDecoder::DoFastForward() has a
> loop requesting GetKeyframePosition(i) to fill in the position
> map one item at a time. Therefore, the RemoteEncoder function
> requests these one at a time. Perhaps a function could request
> an array of keyframes. DoFastForward already knows the range
> of numbers it needs so maybe they could all be sent in a single
> network transaction. Then it would be only slightly slower.

Yeah, I've been meaning to aggregate the keyframe position requests into one
single request at a time, but haven't found time to do it yet.. Want to?
Shouldn't be all that hard. =)

Isaac

Isaac Richards wrote:
...
> Yeah, I've been meaning to aggregate the keyframe position requests into one
> single request at a time, but haven't found time to do it yet.. Want to?
> Shouldn't be all that hard. =)

Already working on it =). I plan to add a FillPositionMap
in each decoder to grab all the new key frame entries up
to desiredKey in one transcation. I found that a local
30min jump ahead took 18sec so this should help with both
local and remote seeks.

-- bjm

On Sunday 11 May 2003 12:06 am, Bruce Markey wrote:
> Isaac Richards wrote:
> ...
>
> > Yeah, I've been meaning to aggregate the keyframe position requests into
> > one single request at a time, but haven't found time to do it yet.. Want
> > to? Shouldn't be all that hard. =)
>
> Already working on it =). I plan to add a FillPositionMap
> in each decoder to grab all the new key frame entries up
> to desiredKey in one transcation. I found that a local
> 30min jump ahead took 18sec so this should help with both
> local and remote seeks.

Excellent, thanks.

Isaac

there's been a lot of activity in this thread, but i still think my
original problem isn't being considered. if i'm not mistaken, the main
thing that bruce is talking about still pertains only to watching
recordings (or livetv) while they're still being recorded. whereas my
'commecial skiping sucks' refers to watching the show long after
recording is complete.

are these two issues still related? i am definitely still seeing it,
three programs recorded today while i was out and all of them skip
wonderfully. i watched one while it was recording yesterday and
skipping sucks on it (watching it again today).

anyway, seems like this problem doesn't bother anyone else, but i wanted
to point out where this all started.

thanks,

CraigL->Thx();

>>>>> On Sun, 11 May 2003 02:09:02 -0400, Craig Longman <craigl@begeek.com> said:

c> there's been a lot of activity in this thread, but i still think my
c> original problem isn't being considered. if i'm not mistaken, the
c> main thing that bruce is talking about still pertains only to watching
c> recordings (or livetv) while they're still being recorded. whereas my
c> 'commecial skiping sucks' refers to watching the show long after
c> recording is complete.

Really? That's not what you said. You said:

c> show b)

c> records from 2000-2100. i'm home while this is recording, so i decide
c> to watch it. i watch it and like it very much, so at 2130h, i decide
c> i want to watch it again. now, when i skip commercials, its
c> unbearably slow, with lots of disk activity, like there is no
c> seektable.


If you're watching at 2130h, as far as MythTV is concerned,
recording is not complete -- you're watching it while it's recording.
It doesn't matter whether you're 30 minutes behind or 1 minute
behind. Chris, Bruce, and Isaac have explained in great detail why
commercial skipping is slow in this case.

If what you're saying now is that commercial skipping is slow
(today) on a program that finished recording yesterday, then that's
something else.

--
Gregorio Gervasio, Jr.
gtgj@pacbell.net

Craig Longman wrote:
>
> there's been a lot of activity in this thread, but i still think my
> original problem isn't being considered. if i'm not mistaken, the main
> thing that bruce is talking about still pertains only to watching
> recordings (or livetv) while they're still being recorded. whereas my
> 'commecial skiping sucks' refers to watching the show long after
> recording is complete.

Given that you are referring to seeing these problems after
the recording has finished, you're right, that hasn't been
addressed.

> are these two issues still related?

Quite possibly so.

> i am definitely still seeing it,
> three programs recorded today while i was out and all of them skip
> wonderfully. i watched one while it was recording yesterday and
> skipping sucks on it (watching it again today).
>
> anyway, seems like this problem doesn't bother anyone else, but i wanted
> to point out where this all started.

I don't think this is usual behavior that everyone is seeing
which would explain why it doesn't seem to bother anyone else.

Here are some possible explanations that come to mind from
more likely to less likely:

-) When watching while recording, the CPU is pegged causing the
file to have lots of missing frames and throwing off the timecodes
and frame rate. If this is the case, you would see the video
speeding up and slowing down and possibly hear choppy audio. See:
http://www.mythtv.org/docs/mythtv-HOWTO-19.html#ss19.4 . Watch
"top" to see if your CPU idle time is near zero during playback
while recording.

-) mythbackend crashes, dies or is killed before the recording
ends. The seektable and blank frame info wouldn't be written
and it would behave worse than watching while recording.

-) Your database schema doesn't have the 'recordedmarkup' table.
Unlikely. Commercial skips would suck for all pre-recorded.

-) Manual recording. The few times I tried this it didn't seem
to have the seek information after after it finished. I never
looked to see why.

The first seems most likely because if the CPU was busy but
keeping up while recording only, watching at the same time might
push it over the edge. Several people reported 'damaged' files
around the time of the 0.8 release if the CPU was pegged and/or
the MPEG4 quality setting where changed drastically.

-- bjm

On Sunday 11 May 2003 07:15 am, Bruce Markey wrote:
> Craig Longman wrote:
> > there's been a lot of activity in this thread, but i still think my
> > original problem isn't being considered. if i'm not mistaken, the main
> > thing that bruce is talking about still pertains only to watching
> > recordings (or livetv) while they're still being recorded. whereas my
> > 'commecial skiping sucks' refers to watching the show long after
> > recording is complete.
>
> Given that you are referring to seeing these problems after
> the recording has finished, you're right, that hasn't been
> addressed.

The most likely thing is that the commercial finding thread hasn't finished,
or wasn't allowed to finish for some reason.

Isaac

Gregorio Gervasio Jr. wrote:

>>>>>>On Sun, 11 May 2003 02:09:02 -0400, Craig Longman <craigl@begeek.com> said:
>>>>>>
>>>>>>
>
>c> there's been a lot of activity in this thread, but i still think my
>c> original problem isn't being considered. if i'm not mistaken, the
>c> main thing that bruce is talking about still pertains only to watching
>c> recordings (or livetv) while they're still being recorded. whereas my
>c> 'commecial skiping sucks' refers to watching the show long after
>c> recording is complete.
>
> Really? That's not what you said. You said:
>
>c> show b)
>
>c> records from 2000-2100. i'm home while this is recording, so i decide
>c> to watch it. i watch it and like it very much, so at 2130h, i decide
>c> i want to watch it again. now, when i skip commercials, its
>c> unbearably slow, with lots of disk activity, like there is no
>c> seektable.
>
> If you're watching at 2130h, as far as MythTV is concerned,
>recording is not complete -- you're watching it while it's recording.
>It doesn't matter whether you're 30 minutes behind or 1 minute
>behind. Chris, Bruce, and Isaac have explained in great detail why
>commercial skipping is slow in this case.
>
no, reread it again. the show was OVER at 2100, and i was watching it
at 2130h. shouldn't be recording anything at that time, right? ;-)

but, the same unusable slowdown will be present 24 hours later, so i
could have as easily said the next day.


CraigL->Thx();

Bruce Markey wrote:

> Craig Longman wrote:
>
>> anyway, seems like this problem doesn't bother anyone else, but i
>> wanted to point out where this all started.
>
> I don't think this is usual behavior that everyone is seeing
> which would explain why it doesn't seem to bother anyone else.
>
> Here are some possible explanations that come to mind from more likely
> to less likely:
>
> -) When watching while recording, the CPU is pegged causing the
> file to have lots of missing frames and throwing off the timecodes
> and frame rate. If this is the case, you would see the video speeding
> up and slowing down and possibly hear choppy audio. See:
> http://www.mythtv.org/docs/mythtv-HOWTO-19.html#ss19.4 . Watch
> "top" to see if your CPU idle time is near zero during playback
> while recording.

no, i see no skipping either in live mode nor in the actual recording.
the cpu usage is <25% (hardware mpeg).

> -) mythbackend crashes, dies or is killed before the recording
> ends. The seektable and blank frame info wouldn't be written and it
> would behave worse than watching while recording.

no, it manages to run fine. infact, after recording shows i watched
(when no seektable was written) the next day it recorded something i
didn't watch and the seektable was right.

> -) Your database schema doesn't have the 'recordedmarkup' table.
> Unlikely. Commercial skips would suck for all pre-recorded.

no, the tables there and has lotsa rows in it. as i said though, i can
reliable cause it to happen/not happen by watching/not watching the show
while its recording.

> -) Manual recording. The few times I tried this it didn't seem
> to have the seek information after after it finished. I never
> looked to see why.

nope, scheduled.

> The first seems most likely because if the CPU was busy but
> keeping up while recording only, watching at the same time might
> push it over the edge. Several people reported 'damaged' files
> around the time of the 0.8 release if the CPU was pegged and/or
> the MPEG4 quality setting where changed drastically.

no, i've been keepign a closish eye on this as its only an ahtlon 1GHz (
i can't believe 1GHz machines are questionably good enough for something
already! ;-)

anyway, i guess i'll keep looking into it. it is so easy to reliably
reproduce that i'm 110% confident its a bug, just not sure why only i
see it. thanks for the suggestions though!


CraigL->Thx();

On Sunday 11 May 2003 11:45 am, Craig Longman wrote:
> anyway, i guess i'll keep looking into it. it is so easy to reliably
> reproduce that i'm 110% confident its a bug, just not sure why only i
> see it. thanks for the suggestions though!

If you're that confident that it's a bug, then fix it. Send in a patch.
Sending email after email about the same minor issue isn't exactly
productive, and just creates noise on the list.

Isaac

>>>>> On Sun, 11 May 2003 11:34:07 -0400, Craig Longman <craigl@begeek.com> said:

[...]

c> no, reread it again. the show was OVER at 2100, and i was watching it
c> at 2130h. shouldn't be recording anything at that time, right? ;-)

Duh. Sorry.
--
Gregorio Gervasio, Jr.
gtgj@pacbell.net