[Solved, partially] TVheadend - help with buffering on Live TV

james · 16 June 2016 02:17

Hi folks

I just picked up a Vero2 and it’s working well so far. A couple of setup glitches but that’s another topic.
I am having issues with buffering/stuttering Live TV (DVB-T) using TVHeadend and a Sundtek Media Pro Tv stick.

I’ve installed TVHeadend from the OSMC App Store and the PVR TVHeadend client Add-On, the setup for this has all gone well. The TVHeadend interface is showing the correct device, services and channels as expected. The installation of the Sundtek drivers was painless.

I can get a Live TV signal initially with very good quality but within a random amount of time (within a minute) one or more of these things will happen:

the video signal will break up / buffer
the audio will stutter
the video signal will pause for a long time and then play again
sometimes it looks like the video is trying to catch up with the audio and will play at high speed until it’s caught up.

I’ve read lots of forum threads and attempted some of the suggestions:

disabled Idle Scanning in the TVHeadend web interface for the DVB-T device.
add an advancedsettings.xml in ~/.kodi/userdata/advancedsettings.xml with the following settings in the correct XML format within the element:

minvideocachelevel = 50, minaudiocachelevel=50, cacheindvdplayer = true (i’ve tried variants of these)

in the element:

cachemembuffersize = 20000000, readbufferfactor = 4.0 (the default). I’ve tried variants of cachemembuffersize with higher values and a value of zero

… all with not much of an effect, still buffering. My previous HD/PVR set top box worked fine until it died so I don’t think it’s a signal issue.

Other options suggested via various forums:

Increase net.core.rmem_max and net.core.wmem_max on the box
turn Full mux reception ‘off’ in TVH - can’t find that setting and think it’s been removed (Bug #1766: Option 'full mux reception' should be disabled by default - Tvheadend)

I’ve also tried playing the network stream from the TVH backed on my laptop via VLC, by copying and pasting the “Play” URL into VLC’s Play Network Stream - this also buffers but that’s putting Wi-Fi into the mix as well

At this point I’m trying to work out whether it’s a tvheadend issue, a sundtek issue or an osmc/kodi configuration issue by isolating the problem. Before I setup the Sundtek Stick and TVH on an old linux laptop I have, are there any more settings I can try in osmc/kodi/tvheadend that would alleviate the buffering?

Interesting logs from /var/log/mediasrv.log:

2016-06-16 11:37:02 [472] Tuning DVB-T frequency: 191500000
2016-06-16 11:37:03 [472] Resetting TS Port FE1 (1)
2016-06-16 11:37:04 [472] Setting Frequency: 177500000
2016-06-16 11:37:04 [472] Tuning DVB-T frequency: 177500000
2016-06-16 11:37:05 [472] Resetting TS Port FE1 (1)
2016-06-16 11:37:05 [472] TS Sync byte not aligned, realigning stream (5640 // 168)
2016-06-16 11:37:21 [472] Setting Frequency: 191625000
2016-06-16 11:37:21 [472] Tuning DVB-T frequency: 191625000
2016-06-16 11:37:33 [472] Setting Frequency: 177625000
2016-06-16 11:37:33 [472] Tuning DVB-T frequency: 177625000
2016-06-16 11:37:50 [472] Setting Frequency: 226500000
2016-06-16 11:37:50 [472] Tuning DVB-T frequency: 226500000

The buffering occurs when TS Sync byte not aligned appears in the logs.

In the TVH debug area I see logs like these whenever buffering takes place.

016-06-16 12:02:47.013 TS: Freeview/219.625MHz/TEN Digital: MPEG2VIDEO @ #512 Continuity counter error (total 1)
2016-06-16 12:02:47.013 TS: Freeview/219.625MHz/TEN Digital: MPEG2AUDIO @ #650 Continuity counter error (total 1)
2016-06-16 12:02:47.013 TS: Freeview/219.625MHz/TEN Digital: TELETEXT @ #576 Continuity counter error (total 1)

Do I need an mpeg2 license for the Vero2 ?

I’m ok with delving into logs and config on Linux so if there is anything further I need to provide let me know

Thanks
James

mrechberger · 16 June 2016 05:21

looks like latency issues, what are the cpu settings?

what does following command show up:
/opt/bin/mediaclient --cpucheck
or
mediaclient --cpucheck (in case the first one doesn’t work)

what does the overall cpu load look like?

james · 16 June 2016 06:10

Top shows the process usage like this:

  529 osmc      20   0  980412 434080  24344 S  74.9 53.2 181:24.23 kodi.bin                                                         
  639 osmc      20   0  295236  18756   5732 S  11.6  2.3  17:45.97 tvheadend                                                      
  475 root      20   0   83804  10472   5676 S   6.0  1.3  15:59.17 mediasrv

kodi is using quite a bit of CPU, followed by tvh, spread over all the CPUs:

top - 16:10:51 up  3:32,  1 user,  load average: 1.01, 1.29, 1.31
Tasks: 114 total,   3 running, 111 sleeping,   0 stopped,   0 zombie
%Cpu0  :  4.4 us,  3.3 sy,  0.0 ni, 91.6 id,  0.0 wa,  0.0 hi,  0.7 si,  0.0 st
%Cpu1  :  9.8 us, 45.4 sy,  0.0 ni, 44.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu2  :  7.9 us,  5.6 sy,  0.0 ni, 86.1 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
%Cpu3  : 19.2 us,  9.6 sy,  0.0 ni, 70.5 id,  0.0 wa,  0.0 hi,  0.6 si,  0.0 st
KiB Mem:    815320 total,   746780 used,    68540 free,    29944 buffers
KiB Swap:        0 total,        0 used,        0 free.   194168 cached Mem

Load average hovers around like this:

top - 16:09:36 up 3:31, 1 user, load average: 1.58, 1.41, 1.35

$ sudo /opt/bin/mediaclient --cpucheck
Sundtek CPU Check

cpu0:
   current scheduler: interactive
   available schedulers: hotplug interactive 
cpu1:
   current scheduler: interactive
   available schedulers: hotplug interactive 
cpu2:
   current scheduler: interactive
   available schedulers: hotplug interactive 
cpu3:
   current scheduler: interactive
   available schedulers: hotplug interactive

Thanks for your help

James

mrechberger · 16 June 2016 08:28

Try to contact us via Chat on Friday (not today/Thursday) I think we would have to have a look remotely to see if there’s anything that can be done.

http://chat.sundtek.de

james · 17 June 2016 02:39

Thanks

I removed 3 addons installed when I was playing around with the Vero2 on setup to see if that may cause some heavy CPU usage but no change.

One thing I noticed is that the TV signal now starts out OK but after a minute or so it’ll buffer then completely stop. The CPU usage by kodi.bin then hits over 100% CPU and the device doesn’t respond to the remote.

These items appear in the TVH log:

2016-06-17 12:25:19.455 TS: Freeview/226.5MHz/ABC2/KIDS: MPEG2VIDEO @ #2307 Continuity counter error (total 2)
2016-06-17 12:25:19.455 TS: Freeview/226.5MHz/ABC2/KIDS: MPEG2AUDIO @ #2308 Continuity counter error (total 2)
2016-06-17 12:25:19.456 parser: transport stream TELETEXT, DTS discontinuity. DTS = 39475664, last = 39157064
2016-06-17 12:25:19.840 parser: transport stream MPEG2VIDEO, DTS discontinuity. DTS = 39523663, last = 39206863
2016-06-17 12:25:19.840 parser: transport stream MPEG2AUDIO, DTS discontinuity. DTS = 39489120, last = 39150000

I’m in +10 timezone so I’ll leave the chat to this evening, hopefully this can be sorted. I haven’t had any signal issues up until now.

cpeters · 17 June 2016 05:31

Hey, I also use the Sundtek Stick and what you write now, sound exactly like my problem here:

Unfortunately I also do not have a solution to this, yet

sam_nazarko · 17 June 2016 18:00

I will reply with my thoughts on the other thread shortly.

Sam

james · 18 June 2016 04:03

Ok thanks, I’ll watch that topic and see what comes up and contact Sundtek separately.

I ran top while playing with the TV functions. kodi.bin usually hovers around 20-40% CPU (which to me is a lot but I’m no expert on kodi ). When I play any TV channel, kodi.bin jumps up above 100% CPU and load is >= 1.

sam_nazarko · 18 June 2016 14:51

I meant this thread, as it is more recent, my mistake.

The Sundtek brand of DVB tuners are good because they do not break when the kernel DVB API changes. I have one somewhere but it may take a while for me to locate it.

It would be good if you could try streaming from another computer, or pre-record a stream and see if you still exhibit playback problems.

I need to know whether the issue is with playback or the USB interface itself. When you are playing back a stream, can you press the ‘O’ key on a remote and note if you see any skipped frames. It would also be good to see whether it’s being hardware decoded (amcodec or ffmpeg).

We are using the same USB block as the Raspberry Pi did, and there were similar issues with USB isochronous transfers in the past. We need to check if the tuner is using isochronous endpoints. To do this, please try run the following commands:

sudo apt-get update
sudo apt-get install usbutils
lsusb -v

I would also expect SD channels to have fewer glitches than HD channels. We have explored a FIQ implementation, which is how Raspberry Pi achieved their USB performance and resolved a number of problems, but it seems to give us undesired side effects. There are a couple of other methods we can employ to make sure a microframe is not delayed by more than 125us (which is what is likely causing the problem, if it is not playback related).

I’ll see if I can get a couple of changes in for the next update that may improve some things.

Sam

james · 19 June 2016 10:07

Hi Sam

I had an old(er) i3 laptop (4x CPU / 4GB RAM) running Kubuntu Wily (15.10) which I updated and installed the tvheadend package from their own repo (v4.0.9). I set it all up and was able to connect using the Add-On on the Vero.

With TVH running on the laptop there is minimal stuttering or ‘buffering’ - some little blips/pops in the audio throughout watching a program and some video artefacts when first selecting TV on the Vero. TVH GUI says the signals strength is 100%

When handling TV from the laptop, the kodi.bin process uses between 30 and 90% CPU (I’ve uninstalled the TVH server on the Vero), nowhere near the 100-160% I’ve seen when the TVH server was running on the same machine.
I don’t know if that’s related to the version on the Vero (4.0.7) or something else.

Can I install the 4.0.9 server from the APT repo provided by TVH on the Vero or does it have some special stuff going on?

It would also be good to see whether it’s being hardware decoded (amcodec or ffmpeg)

Hardware decoding was enabled in the Vero settings but I do notice log lines in kodi.log like this:

12:12:21 T:2609902576  NOTICE: Creating video codec with codec id: 2
12:12:21 T:2609902576   ERROR: Unable to load libamplayer.so, reason: libamplayer.so: cannot open shared object file: No such file or directory
12:12:21 T:2609902576 WARNING: CAMLCodec::CAMLCodec libamplayer.so not found, trying libamcodec.so instead
12:12:21 T:2609902576  NOTICE: Creating video thread

and lots of

12:13:01 T:2564813808 WARNING: CDVDMessageQueue(video)::Get - asked for new data packet, with nothing available

and every now and then:

12:14:03 T:2876646384 WARNING: CPythonInvoker(0, /usr/share/kodi/addons/script.module.osmcsetting.updates/service.py): the python script "/usr/share/kodi/addons/script.module.osmcsetting.updates/service.py" has left several classes in memory that we couldn't clean up. The classes include: N9XBMCAddon7xbmcgui12ControlImageE,N14PythonBindings31XBMCAddon_xbmc_Monitor_DirectorE,N9XBMCAddon7xbmcgui6WindowE

Long output from the Sundtek stick plugged into the i3 laptop below (sorry can’t upload plain text files here) when I can make the time to plug it all back into the Vero I’ll grab the lsusb output from there if needed.

Bus 001 Device 003: ID 2659:1210 Sundtek MediaTV Pro III (EU)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x2659 Sundtek
  idProduct          0x1210 MediaTV Pro III (EU)
  bcdDevice           40.01
  iManufacturer           1 Sundtek
  iProduct                2 MediaTV Pro III (EU)
  iSerial                 3 U160606231053
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          344
    bNumInterfaces          7
    bConfigurationValue     1
    iConfiguration          4 MediaTV Pro III (EU)
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             32 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x8e  EP 14 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               4
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x0e  EP 14 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0020  1x 32 bytes
        bInterval               4
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         1
      bInterfaceCount         6
      bFunctionClass        255 Vendor Specific Class
      bFunctionSubClass     255 Vendor Specific Subclass
      bFunctionProtocol     255 Vendor Specific Protocol
      iFunction               0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              7 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x8f  EP 15 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval               7
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              8 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              9 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       2
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             10 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0080  1x 128 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       3
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             11 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x013c  1x 316 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       4
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             12 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x02c8  1x 712 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       5
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             13 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0ac8  2x 712 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             20 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             21 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x001c  1x 28 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        3
      bAlternateSetting       2
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             22 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0034  1x 52 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             23 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             24 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x00b8  1x 184 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       2
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             25 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x02d8  1x 728 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       3
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             26 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x13c4  3x 964 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        4
      bAlternateSetting       4
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             27 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0b84  2x 900 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        5
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             28 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x85  EP 5 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        5
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             31 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x05  EP 5 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        6
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             29 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        6
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface             30 MediaTV Pro III (EU)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0240  1x 576 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

Thanks
James

sam_nazarko · 19 June 2016 13:21

Not exactly – but 4.0.9 will be made available today via our APT Store. I don’t necessarily think that’s the issue though.

That’s not an error. Hardware acceleration used to be provided via a large libamplayer.so library, but for a while now AMLogic have provided us with libamcodec.so. This is smaller, but Kodi tries libamplayer before falling back.

Nothing you’ve really pasted is an error – but ask for new data… means that the buffer is likely underrunning. [quote=“james, post:10, topic:17260”]
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
[/quote]

I’ve implemented some changes in today’s kernel that means transactions won’t be queued if we don’t have enough time in the microframe to handle them. This may give you some improvements. Let me know how you get on after the update is released.

Sam

james · 20 June 2016 04:44

Thanks Sam, I have applied the June update and have reinstalled the TVH Server (4.0.9). I’ll leave it running for a while and see how it goes then report back.

Only change I made in the client is that I switched the client to connect to the TVH server on 127.0.0.1 instead of the device’s IP address (192.168.etc) … as it’s on the same machine to reduce the chance of network issues.
On that note, I don’t know if it’s possible to get the client to talk to the server over a Unix socket ?

james · 21 June 2016 02:01

Hi Sam

I’ve played LiveTV via the Sundtek stick and the Vero2 for a few hours yesterday and today.
The playback is much better with the latest updates than with the May updates although not as good as running TVH 4.0.9 on the separate i3 laptop

Still getting both audio and video stuttering, random pauses and what I’d call buffering. One of the following happens:

The video and audio signal will pause while watching and the program information captions will show by itself without being requested
the video will show with no audio and within 10 seconds or so the audio will kick in and then they’ll sync up.
the video often plays very quickly, looking like it’s trying to catch up with the audio
the video will pause, the audio will play and then the video will jump to the audio position.

If I play TV via VLC over a Wireless N connection on my laptop by opening the stream then there are frequent pauses in both audio and video at the same time.

I’m going to try a different cable and and a separate TV with it’s own tuner in the same location to see if it’s a location issue. My previous PVR which died was I think a homecast model with a dual tuner - I think only 256MB RAM and some weirdo embedded linux setup - had no issues playing both SD and HD and never had any signal issues using the same cable.

Do you know of any other options that can be tried. I’ve fiddled with an advancedsettings.xml file with various buffering and caching options with little success.

Running the sundtek mediaclient --cpucheck does result in this for all CPUs:

$ /opt/bin/mediaclient --cpucheck
Sundtek CPU Check

cpu0:
   this cpu is using the ondemand scheduler
   this might cause some performance issue, please take care
   that the cpu frequency will not change while using the
   TV Tuner

   current scheduler: ondemand
   available schedulers: ondemand performance 
   to change the scheduler you might run following command:

   echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Many thanks
James

Gmoney · 21 June 2016 02:22

so i know i’m not supposed to complain about something without taking the time to gather logs and what not, but, in the event it helps isolate something here… i’m using two HDHomeRun EXTEND tuners (tried both with and without hardware transcoding), one tied to a US digital cable (ClearQAM) signal and the other to an OTA antenna with marginal reception and OSMC on a RPi2 and i have the EXACT same issues as James. I’ve had the issues for a while and have just lived with it as i had NO idea where to start (is this TVHeadEnd server issue, network issue, tuner issue… the list can go on, but i’ll stop there).

I will say that if a record a show and then play it back, i have no issues. So sometimes i find myself recording a show only so i can “play from beginning” and get good behavior. But if i catch up with realtime, sometimes OSMC locks up and there’s only one way that i know of to get it back… sudo reboot (or pull the plug). Oh yeah, both buffering and PVR record destinations are a NAS. Buffering to a local USB stick didn’t seem to help.

I also watch movies from the same NAS with no issues whatsoever. This seems to debunk my latest theory which is that my network chip (also handles the physical layer of the USB traffic) is overheating… yeah, i’m grasping at straws here.

Anyhow, i’m only chiming in with additional info that i hope helps debug this issue. Since i haven’t taken the time to post log files, i’m not asking for help. HOWEVER, if anyone would like me to check something specific, post a log file, or try some particular setting, just let me know. Good luck, cause i’d love to see this problem licked.

james · 21 June 2016 03:24

I should add that in my case

the buffering location is on the Vero
the Vero can play video from a NAS over DLNA/upnp, both devices are connected by cable to an extender that is connected to a router doing DHCP
the CPU usage of both TVH and kodi.bin dropped quite a bit since the June update, which is good

As I see it there are lots of factors at play here:

the specific TVH server that is installed from the OSMC App Store and it’s configuration
the pvr.hts (?) TVH AddOn client installed on the Vero and it’s configuration
the Vero hardware itself
the kodi configuration
the Sundtek tuner configuation
Signal quality / cabling
Hardware acceleration (off is worse than on)
Deinterlacing (been alluded to but I can’t find the setting)

All bugs are solved by reducing the problem - by streaming to VLC directly from the server, we can bypass (2) but that invokes possible local network issues but I don’t expect that to cause buffering.
There is also a decent Android client called TVHClient that I’ll test out to see how the stream plays to my phone screen.

There are also eleventy-billion different webpages with configuration options for Kodi + TVH and not all of them are up to date. The most recent suggest turning off “Idle Scan” in the TVH options for the tuner.

On the Sundtek side I can only see --ts-settle-timeout as a possible option that was mentioned but their docs say this:

 --ts-settle-timeout=[0-4000]  timeout in milliseconds before data should be sent from
                               the driver to the application after changing the transponder
                               (DVB-S/S2 supports this)

… not sure if that applies to DVB-T

I don’t know enough about this to make any further headway really other than to think that the TVH server could somehow lower then signal quality to see if the Vero2 can keep up.

I am surprised with the Live TV issues, though, given that the Vero is sold as “Vero 2 features a fast quad core processor and a dual core GPU. Whatever you throw at it, Vero will handle it.” Something is not quite right and unfortunately there are a lot of different factors at play. Whatever it is, a person with no Linux experience would have absolutely no hope of working this out.

sam_nazarko · 22 June 2016 01:18

Hi

This would suggest that perhaps the issue is with isochronous transactions via USB, rather than the device not being able to keep up.

Let’s eliminate another variable from the situation. If you can do so, please test using a Wired network connection for now.

Where it gets interesting is @Gmoney’s comments about a HDHomerun tuner. I believe they are not connected via USB but actually reside on the local network? My first recommendation would be to play back using the HDHomerun plugin first, independently of TVHeadend. While I am not convinced TVHeadend is at fault, there have certainly been some unexpected regressions in recent versions that have caused some issues, and it would be good to rule that out for definite.

Network sits on a separate PHY from USB. I don’t think your network interface is overheating or underperforming. An iperf test would obviously confirm that.

I think we may have two potential issues here. Inadequate USB throughput for DVB based streaming and a potential problem with TVHeadend which affects network tuners. The symptoms may be the same, but I’m not sure that the cause is. As mentioned previously, I’d love to know:

I am on holiday in a few hours, but I will look at this issue when I get back and would appreciate your feedback in the interim. I will still be available periodically on the forums.

Appreciated – but TVHeadend is not for the faint of heart either. Unfortunately variables such as tuner used, signal strength etc and TVHeadend being a constant moving target are why we have not offered DVB solutions ourselves at this time.

Can you also confirm if SD channels behave better, as suggested above?

Sam

james · 22 June 2016 23:38

Hi Sam

Some success but some answers to your questions:

The Allow Hardware acceleration setting is enabled in Video / Acceleration - is that what you mean?

There is no O on the remote but if I tap the icon that looks like the unordered list icon in the editor here it shows a dropped & skipped value along with some bandwidth values and more. Dropped increases slowly, last time I was was watching it had increased to 350, skipped stayed on zero.

I’m not sure if the HDHomeRun plugin/addon is related to my setup with the Sundtek stick

The Web UI is extensive and could be laid out in a more understandable way but it’s fairly easy to understand (for me) once the process of Tuner > Network > Muxes > Services and the Channels is understood. The only bugbear is that some services which I know can be received end up in Scan Pending / Failed and the force rescan doesn’t pick them up.
Just been spoilt with Auto Tuning on HDTVs I think

Now some success –

I read through the Sundtek Driver Configuration again and the following options look related to what you’ve said

Sundtek Media TV Pro Linux Installation
Changing the transfermode for DVB-T/C from Isochronous to Bulk (some embedded PCs do not support Isochronous transfer with linux), this option can also work around some possible kernel isochronous bugs which are in 2.6.26-2.6.29 and 2.6.32.9 - 2.6.33.1.

By default when the devices are shipped, the device will be in Isochronous mode
To change it to Bulk:
$ /opt/bin/mediaclient --dtvtransfermode=bulk -d /dev/dvb/adapter0/frontend0
Setting transfermode to Bulk
Please reconnect your device in order to activate the transfer mode change

I switched the transfermode over to Bulk and also changed the following settings in an /etc/sundtek.conf file, then rebooted the Vero

/etc/sundtek.conf

autoupdate = off
loglevel = max
use_hwpidfilter = on
ir_disabled = 1

I think use_hwpidfilter is the most relevant given the explanation “The PID Filters can lower the required USB 2.0 bandwidth significantly - this is recommended for embedded PCs.”

I turned off IR as that’s being handled by the Vero and it’s one less thing running. loglevel max so I can get more info about what’s going on.

With those changes the SD viewing is much much smoother but HD is still choppy on the Vero.

If I use the TVHClient Android App to stream (mux=webm) from the TVH server directly both SD and HD signals only present a pause every 2-3 minutes or so of video and audio for about a second or two then it kicks back in.
This is being streamed over Wifi in the 5Ghz band to my phone.

I’ll try that out. Currently the Vero is connected via cable directly to a Wifi Extender to a Router doing DHCP. I’d hope that plugging a laptop into the Extender would keep the traffic there and not pass it via Wifi to the router but who knows. I could do a traceroute I guess.

Other things:

Still getting log lines like this in mediasrv.log but far less of them

2016-06-23 09:19:15 [506] Resetting TS Port FE1 (1)
2016-06-23 09:19:15 [506] TS Sync byte not aligned, realigning stream (0 // 104)

and with matching timestamps from the TVH debug area (athough sometimes continuity errors without the not aligned errors above):

2016-06-23 09:22:57.404 pass-eit: invalid checksum (len 1099, errors 1)
2016-06-23 09:23:44.472 TS: FreeviewSydney/177.5MHz/7HD Sydney: AC3 @ #579 Continuity counter error (total 13)
2016-06-23 09:23:44.508 TS: FreeviewSydney/177.5MHz/7HD Sydney: TELETEXT @ #580 Continuity counter error (total 12)

Anyway, seems like the Hardware PID and/or Bulk transfer change did some work towards getting this watchable at least on SD. I’ll see how HD goes later on with some drop/skipped frame info.

Thanks
James

Gmoney · 26 June 2016 02:27

Yes, these tuners reside on the local network.

I’m not sure what i’m looking at when i press the ‘O’ key. I don’t see anything that says ffmpeg or amcodec. I also do not know how to determine if there are any skipped frames. I can say that there is a line that shows ‘D(mpeg2video)’, and in the line below, it shows ‘dc:omx-mpeg2’. Furthermore, my HDHomeRun tuner default transcode mode is set to ‘none’, which explains the mpeg2 as that is what most US OTA broadcasters broadcast with. I do have the mpeg2 license installed.

So i don’t know what’s changed, but i used both the HDHomeRun plugin and TVHE and neither are exhibiting the problem! I’ll keep trying both and see if there is a correlation between the two when the bad behavior shows up. For future reference (to myself), the tuner is reporting the following for the channel being tested:
Signal Strength 78%
Signal Quality 73%
Symbol Quality 100%
It might be that the bad behavior shows up when the signal strength/quality drops.

I’ll also try and google the format of the data that shows up when ‘O’ is pressed and see if i can clarify.

sam_nazarko · 26 June 2016 02:31

Are you using a Raspberry Pi? This thread is for the Vero 2. I assumed you were using a Vero 2. You should start your own thread, with logs, in the correct category.

Sam

Gmoney · 26 June 2016 02:46

Welcome back Sam. Hope the few days off was good.

Yes, i’m on a RPi2. I was reading through the original thread and decided to share my issues since my symptoms were the EXACT same and i was NOT on the Vero 2. In my defense, I did state that i was using an RPi2 in my original post . I also stated that i wasn’t necessarily looking for help/answers, but that I was giving extra info that might shed some light on the situation. Looks like i might have done the opposite.

If I decide to pursue help and get motivated enough to collect log files and such, I will most surely start a thread on the RPi2 category.

Thanks Sam and keep up the great work.

Edit: I did find info on the “codecinfo” data that pops up when you press ‘O’. However, i’m missing the skip and drop fields

Edit^2: A cloud must have rolled in between me and the broadcast antenna b/c the tuner signal quality dropped low enough for the symbol quality to be listed as ‘none’. I let it sit there on a pixelated screen for sometime. Eventually, it started stuttering (not really like we’ve been discussing here) so i checked the tuner status and the symbol quality had gone back to 100%. So i pressed ‘O’ but didn’t see any relevant info (since i don’t see the skip and drop). About that time, i get the OSMC frowny face and OSMC restarted. Perhaps more irrelevant information.