Freecom DVB-T channel scan crashes kaffeine
Jan Henrik Sylvester
me at janh.de
Wed Feb 6 08:57:23 PST 2008
> Jan Henrik Sylvester wrote:
>> Compiling scan, make failed since "-include $(wildcard *.d) dummy" is
>> invalid as a line in dvbusb/app/scan/Makefile on its own.
> It builds fine here, make sure you use gmake.
Ok, I did use (BSD-)make.
> 02, 03, and 04 all have the same tuning parameters and use the same
> audio and video pids, only the pmt differs. It seems that these are
> regional channels that were broadcasting the same program at the time
> you were scanning. Try scanning again at different time to see if you
> get different pids.
Thanks, I should have thought of that myself. My assumption that there
is something wrong came from different programs / tuners handling that
>> I often get "dvb dvr read timeout" after double clicking on a channel.
>> Usually it works again after "Stop" and "Play". Is that expected?
> No its' not. Does it happen only when you are switching from one channel
> to another channel, or also when you are tuning to a channel from the
> stopped state? Also is it printed once after a channel switch or every
I cannot reproduce that right now. From my memory, it did not happen
switching from the stopped state and the message is only printed once.
Usually, I was able to switch channels without stopping first, but in
that case, the picture from the previous channel just freezes and
nothing happens. I can double click on the previous channel again to
make in run again, but even after that I need to stop at least once to
be able to switch channels again. From what I remember, that always
worked -- thus, not really a problem.
>> Are the messages from dvbusb I mentioned before expected using Kaffeine?
>> dvbusb_usb_get_packets: Warning discarded 180 unknown bytes
>> discontinuity for pid: 17 expected: 2 got: 8
> Either you are using an old version of the driver or you have build
> the driver with diagnostic on, I suggest you don't build the driver
> with diagnostic to keep your dmesg from getting spammed.
Yes, it is diagnostic. I thought it might have been an indication why
Kaffeine crashes, but since you say it is expected in diagnostic mode,
the problem with Kaffeine is probably really simply a problem of Kaffeine.
BTW: On your homepage, you write that the experimental state of the
driver manifests itself in picture artifacts. I had different problems,
too, that I cannot reproduce right now:
Often, the stick would not take the firmware but give an error message
on dmesg that I cannot remember. I could never fix that by klunloading
and reloading the driver or unplugging and reconnecting the stick to the
same USB port. Anyhow, switching the USB port, the stick would accept
the firmware. If you are interested, I will send you the error message,
if that happens again. (I happened about every other try at the
beginning, but does not happen right now.)
Once, I had FreeBSD crash very probably related to dvbusb. I have never
done that before, but if you are interested, I could try to follow the
chapter about crash analysis from the handbook to try to extract some
information from the vmcore generated. (Just not right now.)
More information about the freebsd-multimedia