Sundtek Support Forum
English => Sundtek MediaTV Pro (Europe) => Thema gestartet von: Yoshi am Juni 05, 2014, 08:09:48 Nachmittag
-
First of all, thanks for your great product!
I don't know if I'm in the right place, but I have no clue if it's Sundtek or TVHeadend to blame ;)
I'm using your MediaTV Home and MediaTV Pro tuners with TVheadend on an ubuntu 14.04 LTS VM. The latest drivers are installed for the tuners and TVHeadend is 3.9.699~gfbe885b. My provider is Ziggo in The Netherlands.
As clients I'm using MacOS (VLC and XBMC 13.0), Windows 8 (XBMC 13.0) and XBMCBUNTU (13.0) and they're all affected.
Now the problem; The Music Choice non-stop radio channels get a few times per minute a hickup in sound. It's a stream of MP2 audio @ VBR. The weird thing is that the XLNT non-stop radio channels -also mp2 audio @ 192kbps- don't suffer the same behavior.
In TVHeadend BER stays at 0, transport- and continuity errors also at 0. Debug logging in TVHeadend shows nothing when the hickup occurs. Same for XBMC logging, no error in the xbmc.log when it occurs.
Is this a known problem? To be sure I offcourse tested the Music Choice radio channels on an official Ziggo tuner and there they're playing just fine.
Any idea?
-
Did you try to record that stream and play it back afterwards?
-
I just recorded a channel with VLC 2.1.4 (Mac OS 10.9) with a .ts file as output. Also hickups in the audio.
-
Did you check other channels on the same transponder (frequency)?
-
I just tried a radio channel in the same transponder as one of the Music Choice channels, RNE radio -MP2 @ VBR and it's also affected. Now I've also tried a TV channel in this transponder and it plays fine. No errors.
Maybe it's just the radio channels with VBR? The channels with fixed bit rate seem to play fine...
-
Are you using VLC to play back the files?
Whatever is carried over the DVB-C network MP2 or VBR MP2 the device doesn't care about that - the endapplication has to support the VBR file actually.
But it might also be that your signal is not properly, you might try to attach the device closer to your cable TV box (just to be sure that your TV cable is not the reason for the hickups).
-
I have to correct myself on the VBR part. What I see is in a sudden drop in bitrate, which I have mistaken for being a VBR stream, and then the hickup occurs.
I just tested with XBMC but it's the same issue with VLC. I can try tomorrow maybe with one of the tuners closer to the cable box, but I'm pretty sure the signal is fine.
I updated the Sundtek driver yesterday and I noticed this: http://support.sundtek.com/index.php/topic,1606.0.html I also have 6875 symbol rate. Should I scan for channels again maybe?
-
There was a change with Symbolrate 6875 indeed, maybe you can contact us via Skype-Chat (sundtek)?
I think it should just work as it, re-scanning possibly might give you some different result.
-
Ok, tomorrow I'll try rescanning. If that has no effect I'll move closer to the cable box.
I'll post the results here. Thanks for the help so far, much appreciated!
-
Already did some testing; rescanning didn't solve the issue. I moved an official Humax Ziggo tuner to the place where my sundtek tuners are. Playback is fine of the mentioned channels. Did a quick signal check in the Humax diagnostics menu and the signal quality is at 100%.
Will try to move the sundtek closer to the cable box later today.
-
I'm very very sorry it took me so long to respond to this topic.
I've tried moving the setup to connect the Sundtek tuner directly to the cable box. The problem persists. Is there any way I can check if this is a bug in the TVHeadend software? The affected channels are all encrypted and I'm using your tuner with a smargo reader. I can't think of any software but TVHeadend to let me play the encrypted channels.
Could you still please be of any help?
Thanks very much :)
-
The freetv ones are all okay?
Try to run /opt/bin/mediaclient --loglevel=max
and then tail -f /var/log/mediasrv.log
what's the output of the driver?
-
Log: http://pastebin.com/v5XyHZsC
I also tried a fresh installation of the Sundtek tuners and TVHeadend on a laptop for testing purposes. Same issue. I think I can rule out a hardware issue on my server?
I only have a few unencrypted radio channels, but those are playing fine.
-
What does /opt/bin/mediaclient --readsignal=20 -d /dev/dvb/adapter0/frontend0 show up (while listening to that channel)?
This is an old MediaTV Pro I or MediaTV Pro II I guess?
The logfile looks okay so far.
-
I have a MediaTV Pro order no. .... and a MediaTV Digital Home order no. .....
== reading digital TV signal ==
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 356 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 357 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 358 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 356 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 358 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 357 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 358 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 356 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 358 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 356 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 358 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 355 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 357 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 358 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 359 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 360 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 358 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 358 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 354 SYM: 6875000 MOD: QAM256
SIGNAL: [.................................] (100%) BER: 0 FREQ: 738000000 Hz LOCKED: YES MER: 357 SYM: 6875000 MOD: QAM256
-
Do you have this issue with both tuners or only one of them?
Those tuners are EOL already, however still supported.
-
Both tuners showing same symptoms.
-
Then you might try it with Windows, maybe your CPU is going to an end with those channels on your target platform (watch it with "top")
According to the log file /var/log/mediasrv.log the stream integrity should be okay. If the stream would be more damaged it would print realigning stream regularly (but according to the log file it only writes those lines after changing the channels).
-
The XBMC client pc's don't show peaks or spikes when playing the error occurs. Those channels are encrypted and I don't know how to decrypt with the smargo using Windows.
About the realigning stream line in the log; you mention it prints this when changing channels. Are you sure about that? I didn't change channels when writing the log. A few seconds before the hiccup occurs, it does print realigning stream.
-
Then something else changed the channel / frequency in the background. The driver itself does not change any frequency - only external applications can trigger that. Try to have a closer look at that, maybe that's your Problem.
-
Maybe it's the second tuner fetching epg data. I'll try the logging with just 1 tuner attached, playing only 1 affected channel.
Edit Yes, turns out to be the epg grab function in TVHeadend.
Can we conclude this issue is not on the Sundtek side but one the TVHeadend side?
-
Were you able to disable the EPG grabbing with tvheadend?
Does it work now?
Yes it's certainly not the tuners fault if tvheadend switches the channel for EPG parsing.
-
I can't find the option in TVHeadend to disable EPG grabbing. It even grabs EPG on the transponder the tuner is using while playback.
What I can see in the status tab in TVHeadend is that the grabbing of the EPG is not causing the hiccups in audio on those radio channels.
I guess something in TVHeadend is causing the messed up audio then :-\
-
just leave the readsignal command running while listening to radio, if it changes the frequency something is wrong.
You can do some EPG settings in the device tab of tvheadend.
-
I disabled one tuner, started listening one of those stations with the remaining tuner. Frequency stays the same, so the changing of the frequency we saw on the previous logging was due to EPG grabbing with the second tuner.
Is there anything else I can try?
I use the git version of TVHeadend and can't disable the EPG grabbing by the way.
-
Windows with DVBViewer, for the rest you need to check in the internet how to get it work.
If no further realigning stream messages show up in the logfile the stream integrity is fine as mentioned, the tuner won't be able to do anything different.
Do you have a configuration file /etc/sundtek.conf ?
-
I don't have a sundtek.conf file.
-
then everything is default, I don't see how the device can cause hickups on your side, it's possibly related that those channels are encrypted/paytv. Maybe increasing the buffers somewhere in the decoding chain might work (please note that we cannot support the software you are using due legal reason).
We certainly support our driver that it delivers data which is okay.
-
I guess this is indeed the conclusion. If I find the time tomorrow maybe I can setup a Windows tv server with Mediaportal.
-
For feedback, did some further investigation and it turns out the Tvheadend stable version doesn't have this issue. So, it's Tvheadend. Thanks for your help!
-
Issue is resolved, bug is removed from git version TVHeadend.
-
Great thanks for your feedback.