On Tue, 16 Aug 2005, Matt Holgate wrote:
> On Tue, 16 Aug 2005, Patrick Boettcher wrote:
>
>> No, unfortunately my suspicion was wrong. I added some debugging, but
>> didn't found the error yet. It seems to be a hard one.
A few interesting things I've found. I don't know if these are red
herrings but:
1) when running tzap under high load, I never see the problem. For
example, if I do:
perl -e 'while (1){}' in one console
and then run tzap 'niced' in another console, I always seem to get a
perfect stream. So I'm wondering if it's a timing issue or something.
2) I'm not sure if this is obvious/expected behaviour (or if I understand
it properly), but whether or not the stream is corrupt or not seems to
depend on the *first* demux that has been setup.
- If I do tzap then dvbstream | mplayer, then I quit mplayer and re-run
it, it will either fail every time or succeed every time.
- If I do tzap -F (to prevent the demux setup in tzap), quitting and
restarting dvbstream/mplayer results in different results each time
(sometimes corrupt, sometimes fine).
This makes me thing it has something to do with the first time a demux is
setup after setting up the frontend.
I don't know if this is of any help, or if it is all coincidental
effects...
thanks,
Matt.
