issues with kaffeine and tvtime, etc.

[JL]

Hello
I have tried the sundtek mediatv pro device in analog mode using tvtime, and dvb-t mode using primarily kaffeine. In both cases I have been able to receive the channels I have access to, but I have experienced some issues.

In the case of analog tv using tvtime (tvtime -d /dev/video0) there appears to be a problem with the audio quality, because there is a (highly annoying) periodically occurring (with a few seconds interval) noise which seems to occur on every channel I've tried. I also quickly tried analog reception using mplayer (mplayer tv:// -tv driver=v4l2:device=/dev/video0), and the same noise is even more prevalent here (no longer periodic, but rather constant). This seems to be a driver issue, because I have no problem with playing audio in my system in any other context (i run Debian/Lenny, and my sound card is a Maudio 2496 card - which is well supported in linux).

When I start tvtime I get the following output;

Running tvtime 1.0.2.
Reading configuration from /etc/tvtime/tvtime.xml
Reading configuration from /home/xyz/.tvtime/tvtime.xml
>>> telling driver daemon that tvtime is opening the devicenode
videoinput: Can't set tuner audio mode: No such file or directory
videoinput: Can't set tuner audio mode: No such file or directory
videoinput: Can't set tuner audio mode: Resource temporarily unavailable 

Like I said, I still get audio though with a rather unbearable periodic noise (I've tried this with the latest driver as well, 090815).
I noticed on the german side of the forum that there are options to change the audio system from internal/external and between alsa/oss, but so far I have only used the default settings (and I don't really know how to change them) and unfortunately my understanding of the german language is rather limited (so I can't really follow the conversations in the german forum).
How do you change the tuner audio mode? How can you tell if alsa is used?

Regarding kaffeine in dvb-t mode, there is another issue. Setting up the system, scanning for channels, etc., was not a problem and for a while the image and audio is perfect. However, I can't watch tv for very long (a matter of minutes most often) before I encounter some error messages in the terminal:
  ..
Stop parsing EIT (0:0)
EIT (0:0) : buffer overflow! Rejected
.....

The above message is repeated numerous times and the image/audio suffers from artifacts until eventually the image reception stops completely and kaffeine crashes (requiring a full system reboot for it to even want to start again). My guess is that this also is some driver issue, because I don't think reception/tv-signal quality is a problem (using dvbt in windows media center / Vista doesn't suffer from this problem).
Is this a known problem, and if so is there a workaround?

My final question is how you switch back to analog mode (what command) if you want to go from using dvb-t  (/opt/bin/mediaclient -D DVBT) to analog, for example? And do you need to unmount the device first?
If so, how?

Some suggestions on how to proceed would be greatly appreciated.

[Sundtek]

Can you send an audio sample to kontakt at sundtek de?

Just run following:

Code: [Auswählen]

cat /dev/video[n] | lame - test.mp3
while tvtime is running


Do you have pulseaudio running?

Maybe also tune to a channel manually as described in the Installation and capture a sample stream

cat /dev/dvb/adapter[n]/dvr0 > test.ts

Maybe if possible can you upload a copy of that stream so we can have a look at it?

Please try to uninstall the driver

Code: [Auswählen]

./empia_installer.sh -u

and reinstall the latest version, we had that overflow issue in earlier versions (it was caused by unsynchronised reads of MPEG data and kaffeine couldn't find out the correct boundaries and interpreted the wrong offsets of the stream). Be sure you can see the Signal strength with kaffeine, only the latest driver version supports this

* What system are you using (32 or 64 bit)?
* What kaffeine Version do you use?

Following is what we get when using kaffeine:
http://pastebin.com/m436b6906

Please verify your signal strength with kaffeine, the linux/xine demuxer might not be as flexible and error resistant as the Windows MPEG Codec.

You do not need to switch the mode back from DVB-T/C to analog TV it is enough to close the DVB application and start tvtime, this is due compatibility to existing Linux Applications.
DVB is visible with /dev/dvb/adapter* interfaces, the driver automatically recognizes if someone wants to switch back to video by accessing the /dev/video* interfaces.

Please note a system reboot should never be required. You can just kill and restart the driver by running.

Code: [Auswählen]

sudo killall mediasrv


[JL]

Hi
I have sent some samples (to kontakt sundtek de) of audio output from tvtime and mplayer while playing analog tv, where the noise/artifacts are clearly heard. If you need additional information, just ask and I will try to provide it to solve the problem.

As for my system. I have a 32-bit system and I do not run pulseaudio (i use alsa in Debian/Lenny, kernel 2.6.26-2-686 with an M-audio 2496 card).

Is there a way to tell the device or the mediaclient to use some specific sound system (like alsa in my case)? So far I have only used the default settings (though I'm not clear on what they are). What other parameters do I have at my disposal for the audio configuration of the device?


I briefly tested kaffeine (v. 0.8.7) for the dvb-t issue, but it would seem the latest driver has resolved the issue (though I need to test some more I think).

regards

[Sundtek]

This seems like a USB issue for some reason, we are grabbing a copy of Debian/Lenny for testing.
Since you're able to capture this noise directly from the driver the audio output seems to be fine. We're checking it.
Do you get any video corruptions?

When using DVB please always double check with the signal strenght.

[JL]

I don't get any obvious video corruption as far as I can tell when viewing analog tv, only audio noise.

Regarding the kaffeine issue, and specifically the new 15/8 version driver, I only just now noticed after doing an unplanned reboot of the system (because Kaffeine crashed). It seems the overflow issue is not the same anymore (no more complaints in the terminal), but switching between dvb-t to analog and back again seems to cause some instability. Simply killing the mediasrv process doesn't seem to be enough, because once the issues occur it seems the entire system becomes unstable and literaly requires a reboot because once kaffeine starts behaving this way it seems it kills itself if i try to restart it. Maybe this behaviour is consistent with some USB issue, because once I got this problem the entire system behaves sluggish and is no longer stable.
The main problem however i noticed after I did the system reboot (the first one after having installed the latest driver version). Now, after KDE (3.5.9 or whatever version is in a stock Debian/Lenny install) is initialized I get this message;

"could not start kdeinit. check your installation"

After this, all things such as proper keyboard layout etc. is not loaded (and obviously whatever other things kdeinit does hasn't been performed). Clearly the new version of the driver is not particularly compatible with debian/lenny, because once I uninstalled the driver and rebooted once more, kdeinit seems to be alright again.

To summerize, the new version of the driver seems to have improved the kaffeine dvb-t experience to some degree but is not really useful for a debian/lenny system because of this kdeinit issue.
I can't think of anything else I migth have done that would have caused this issue, the driver being the only recent change to the system.

 

[Sundtek]

We are currently looking into Debian/Lenny and your particular issue, it shouldn't be a big problem for our engineers to resolve your problem. The main tests have been done with Debian Sarge and Ubuntu for now.

So the KDE error has been resolved, as for Audio we increased the buffer size in the driver (we think it has something to do with the latency on your system, maybe another kernel issue).

A liveCD for verifying the support of those devices will be available within a few days.