Hi all,
A few days ago I got some weird behavior when trying to play back a recorded
rtjpeg video stream. Unfortunately, as a result, I have a stream saved to
disk that I am unable to play. Perhaps one of you have an idea about what
might be going on here, so I will try to be as detailed as possible.
So here was the setup:
* I had scheduled recordings this past Thursday for 8:00-8:30, 8:30-9:30,
and 9:30-10:00 on the same channel. Three recordings in total were the
result of that evening.
* The three recordings were approximately 2.2 gigs for each of the 1/2 hour
slots, and about double that for the hour slot (no surprises there).
And how I first experienced it:
* The next day I went to watch a recorded program, and was able to watch the
first two slots just fine (Friends, and Will & Grace, if you must know...).
It was pretty fun to see the mythBox in action with little trouble at this
point.
* Then, I wanted to watch the third recording (9:30-10:00, the Will & Grace
"best of" show), so I highlighted my selection, watched the little preview
window in the bottom-right corner of the screen start playing fine, and then
clicked the button.
* The hard drive started going nuts at this point, and I had to kill X
forcefully with a ctrl-alt-bksp
Since then, I haven't had a whole lot of time to look into the problem until
today (although I probably shouldn't be, given finals and all). Also,
recordings have since taken place with no further errors.
So this afternoon I fired up SSH on my laptop and had a few sessions going
on the machine -- one with top running, and one in the cvs source tree
handy.
So I wanted to see what was up in 'top' when I tried to run the recording.
I hit play on a few other good recordings to see what was reported. Pretty
standard stuff -- mythfrontend had two processes near the top of the screen,
and both took up about 22M in their size field. Fair enough.
Then I got adventurous and tried running the bad recording. When I started
it, things looked fine at first with 22M but it grew quickly -- 200M, 300M,
422M...until it peaked at an RSS of 483M (makes sense -- 512M in the system)
and a SIZE of 696M!!!
So that freaked me out, and I toyed around with the source. I found my way
inside libNuppelVideo, particularly in NuppelVideoPlayer on around line 496
which looks like the following:
if ( seek_frameheader.packetlength > 0 )
{
char *seekbuf = new char[seek_frameheader.packetlength];
ringBuffer->Read(seekbuf, seek_frameheader.packetlength);
//...
}
Dropping a few cerr lines around there, I noticed that seek_frameheader was
in the 3 hundred millions!!! In fact, it was 381818128 decimal, or 16C21510
hex.
So it appears that when the file was written, the seek frame was incorrectly
written to disk, and now this recording is shot for playback by
libNuppelVideo. Optimally, I'd like to recover the playback, but it doesn't
appear to be highly likely. The file *does* show up on the preview area in
the playbackbox, though...
So what do you guys think about this? It surely is some strange stuff that
is happening, perhaps when two recordings are scheduled to occur one after
another. Perhaps packetlength is incorrectly calculated before writing to
disk, or it gets filled with an uninitialized value or something.
I will hold on to this recording in case you guys want me to check it out or
if you guys come up with an idea to resurrect it (perhaps by running it
through some sort of transcoder to get it in another format to watch...).
Regardless, I think there should be a bit more helpful error checking on the
NuppelVideoPlayer's behalf, since there is clearly the possibility to have
an out-of-whack value read in. I don't know what the maximum sane value
would be here, but it's probably a good idea to figure out so nobody gets
stuck in a weird situation like this again. One time when I wanted to see
how long it'd take to load (before I investigated the problem) it actually
managed to bring the system to its knees and left 400+M of memory allocated
after I killed X...
I hope this serves as a decent bug report for you guys. It took a good hour
and a half to compile. :)
Cheers,
Chris
A few days ago I got some weird behavior when trying to play back a recorded
rtjpeg video stream. Unfortunately, as a result, I have a stream saved to
disk that I am unable to play. Perhaps one of you have an idea about what
might be going on here, so I will try to be as detailed as possible.
So here was the setup:
* I had scheduled recordings this past Thursday for 8:00-8:30, 8:30-9:30,
and 9:30-10:00 on the same channel. Three recordings in total were the
result of that evening.
* The three recordings were approximately 2.2 gigs for each of the 1/2 hour
slots, and about double that for the hour slot (no surprises there).
And how I first experienced it:
* The next day I went to watch a recorded program, and was able to watch the
first two slots just fine (Friends, and Will & Grace, if you must know...).
It was pretty fun to see the mythBox in action with little trouble at this
point.
* Then, I wanted to watch the third recording (9:30-10:00, the Will & Grace
"best of" show), so I highlighted my selection, watched the little preview
window in the bottom-right corner of the screen start playing fine, and then
clicked the button.
* The hard drive started going nuts at this point, and I had to kill X
forcefully with a ctrl-alt-bksp
Since then, I haven't had a whole lot of time to look into the problem until
today (although I probably shouldn't be, given finals and all). Also,
recordings have since taken place with no further errors.
So this afternoon I fired up SSH on my laptop and had a few sessions going
on the machine -- one with top running, and one in the cvs source tree
handy.
So I wanted to see what was up in 'top' when I tried to run the recording.
I hit play on a few other good recordings to see what was reported. Pretty
standard stuff -- mythfrontend had two processes near the top of the screen,
and both took up about 22M in their size field. Fair enough.
Then I got adventurous and tried running the bad recording. When I started
it, things looked fine at first with 22M but it grew quickly -- 200M, 300M,
422M...until it peaked at an RSS of 483M (makes sense -- 512M in the system)
and a SIZE of 696M!!!
So that freaked me out, and I toyed around with the source. I found my way
inside libNuppelVideo, particularly in NuppelVideoPlayer on around line 496
which looks like the following:
if ( seek_frameheader.packetlength > 0 )
{
char *seekbuf = new char[seek_frameheader.packetlength];
ringBuffer->Read(seekbuf, seek_frameheader.packetlength);
//...
}
Dropping a few cerr lines around there, I noticed that seek_frameheader was
in the 3 hundred millions!!! In fact, it was 381818128 decimal, or 16C21510
hex.
So it appears that when the file was written, the seek frame was incorrectly
written to disk, and now this recording is shot for playback by
libNuppelVideo. Optimally, I'd like to recover the playback, but it doesn't
appear to be highly likely. The file *does* show up on the preview area in
the playbackbox, though...
So what do you guys think about this? It surely is some strange stuff that
is happening, perhaps when two recordings are scheduled to occur one after
another. Perhaps packetlength is incorrectly calculated before writing to
disk, or it gets filled with an uninitialized value or something.
I will hold on to this recording in case you guys want me to check it out or
if you guys come up with an idea to resurrect it (perhaps by running it
through some sort of transcoder to get it in another format to watch...).
Regardless, I think there should be a bit more helpful error checking on the
NuppelVideoPlayer's behalf, since there is clearly the possibility to have
an out-of-whack value read in. I don't know what the maximum sane value
would be here, but it's probably a good idea to figure out so nobody gets
stuck in a weird situation like this again. One time when I wanted to see
how long it'd take to load (before I investigated the problem) it actually
managed to bring the system to its knees and left 400+M of memory allocated
after I killed X...
I hope this serves as a decent bug report for you guys. It took a good hour
and a half to compile. :)
Cheers,
Chris