Hermann Gausterer wrote:
The simplest explanation would be a bad signal quality. Did you try this test without VDR, for example with szap -i?On Wednesday 28 July 2004 21:52, Hermann Gausterer wrote:i have the scary problem with the "broken data stream" too ... but my sitaution is even worse ... :-(
today was an very "good" day with new info for the problem with
the data-stream-error... :-)
my vdr is now patched and logs the device in use for a started recording and the device which causes the "data-stream-error"
in the syslog.
i found out (at least at my system)
1) the arm on the card, where the "DSE" happens is not dead in
any case; it showed up that an simple restart of VDR without the
removing of any module, this card can produce data again ...
this means that there is something wrong with the handling of this
adapter ... if this happens at driver oder vdr side is out of my
knowledge at this point
2) i modified szap in that way that it opens all of my frontend-devices
and read the status periodically all 10ms and compares it with the previous value ... i have expected that there would be only a change
if a channel is switched ... but that was TOTALLY untrue ... :-o
there are very often status changes on my 1.3 cards, ....
it shows up that the card loses lock for up to 0.5 seconds, and this
shows up with a short blackout on the screen ...
does somebody else get such "short blackouts" ???
after more testing it happens that there was an nearly up to a second
unlock-phase, and after this the screens stay dark, but the status of the card went back to 1F ...
so my conclusion is that the cards are working, vdr tunes to a channel
and starts a recording ... and from time to time short unlock phases happens which shows up with little artifacts on screen at playback ..
and if there is a longer outage, the driver gets "out of sync" and the
recording streams stops here ..
this would explain all points (from my point of view ... of course ;-)
i hope somebody that have this problem too will test this too and
tells the output :-)
i have attached the modified szap, the binary is compiled for a three card setup; compiling like the normal szap, put it in the
dir linuxtv-dvb-apps-1.1.0/util/szap/ ... it can be started at any time
and because it does not open the device in read-write mode
a last questions: can the GET_STATUS ioctl disrupt the normal operation of the
frontend in any way? (there are a lot of ioctls when run the modified
szap .. maybe that could be a point, but if a readonly operation change something, then ...... ;-)
hermann