Media TVPro problems

[Palinkat]

Hi Sundtek forum users,

I have been using my Media TV Pro stick for DVB-T on my VU+ DUO nearly since it came out last year. I have used it on VIX and now have moved to the latest Black Hole 1.5.1 image. I had to move away from VIX altogether because of instability. I am very happy with BH images in general. The problem I have and I had it as well on VIX images is that after a few days, about 5 days, without doing a full reboot of the system, the picture gets blocky, unwatchable and the spinner comes up as if there was a memory issue. I never really got the chance to test why and when this was happening before. First I was trying out various images before sticking to BH for a couple of months now. Then I was also having reception problems and had to get a new antenna with very good signal now.
The issue I have with DVB-T doesn't happen at all with DVB-S2 and my image is very stable. When the breaking up of audio and picture happened, I checked my system memory and there's no spike there.
Only a full reboot fixes it, Enigma 2 restart is not enough. For several days, there are no problems and around the 4th day, the picture starts to break a bit and by the 5th day, it's not watchable anymore.
Does anyone experience the same problem. Can that be an issue with my stick?

Thanks for the help

[Sundtek]

Is this the latest driver?

What does "top" show up on the console (CPU usage of various applications).

There is definitely no memory issue with the driver we reviewed this part closely.

[Palinkat]

Thanks for the reply

I installed the image last week so I presume the Sundtek driver installer connects to your server and downloads the latest drivers available.
Pardon my lack of knowledge, but how I get to this "Top"?

Thanks

[Sundtek]

Can you follow following instruction:
http://support.sundtek.com/index.php/topic,348.0.html


if you run the command "top" in the same terminal you will get the CPU utilization of each application running on your settopbox.

We are currently in Taiwan checking and working on the upcoming hardware from our factory, we don't have access to a VU+ device until 20th May (when we return to Berlin). Basically all settopbox work on our side has to be postponed until that date.

Aside of that we will send Angelofsky a few samples I'm sure we'll figure out your issue sooner or later. Even Dreambox Systems have some detection code in it for some different Image versions, VU+ currently doesn't.

[Palinkat]

Thanks a lot for your support, no pb, have fun in Taiwan.
A little update on the issue though. I use to leave my box on standby on a DVB-T channel. Last week I did a test and left it on a DVB-S channel during standby. After 7 days, I have no issue with DVB-T channels anymore.
So there must be some issue with regards to the stick and standby, hopefully this will make sense to you.

Thanks a lot!!

[rassi]

There is this, now and then. Issues with memory?
Uptime is now 7 days and that looks like it to be pretty maximum uptime to view T-channels with Sundtek. After reboot T-channels are Ok again.

Drivers:
Build date: Mar  5 2012

Code: [Auswählen]

Mem: 135260K used, 3080K free, 0K shrd, 0K buff, 36724K cached
CPU:  2.8% usr 23.2% sys  0.0% nic 33.0% idle 22.7% io  0.0% irq 18.1% sirq
Load average: 5.79 5.25 3.44 4/112 24030
  PID  PPID USER     STAT   VSZ %MEM CPU %CPU COMMAND
   67     2 root     RW       0  0.0   1 21.9 [sched_high]
23037     2 root     SW       0  0.0   0  5.8 [kworker/0:0]
    3     2 root     SW       0  0.0   0  1.8 [ksoftirqd/0]
22707   849 root     S     156m115.7   1  1.5 /usr/bin/enigma2
23610   849 root     S     156m115.7   1  1.5 /usr/bin/enigma2
23921     2 root     SW       0  0.0   1  1.5 [kworker/1:1]
23633     1 root     S     114m 84.4   1  0.9 /opt/bin/mediasrv -d --no-nodes
  860   849 root     S     156m115.7   1  0.7 /usr/bin/enigma2
23644   849 root     D     156m115.7   1  0.5 /usr/bin/enigma2
23945 23931 root     R     2888  2.0   1  0.3 top
   19     2 root     RW       0  0.0   0  0.3 [kswapd0]
23451   849 root     D     156m115.7   1  0.2 /usr/bin/enigma2
23926   581 root     S     2664  1.9   1  0.1 /usr/sbin/dropbear -r /etc/dropbea
   66     2 root     SW       0  0.0   0  0.1 [sched_low]
20855     2 root     SW       0  0.0   0  0.1 [kdvb-ad-0-fe-0]
  852   849 root     D     156m115.7   1  0.0 /usr/bin/enigma2
  890   849 root     S     156m115.7   1  0.0 /usr/bin/enigma2
  935   849 root     S N   156m115.7   1  0.0 /usr/bin/enigma2


[Sundtek]

The memory is virtual memory not physical one. Physical memory should be around 10 mb RAM for the driver constantly we checked the driver accurately for memory leaks last year.
sched_high seems to be not normal with 22% CPU?

Which system is that? it seems to be another issue with it.

[rassi]

Ok, stats are pretty hebrew to me
This was from VU+ DUO


another capture with just rebooted & viewing T-channel

Code: [Auswählen]

Mem: 131832K used, 6508K free, 0K shrd, 0K buff, 44020K cached
CPU:  2.4% usr  4.0% sys  0.0% nic 92.5% idle  0.0% io  0.0% irq  0.8% sirq
Load average: 0.99 1.40 1.41 3/106 5889
  PID  PPID USER     STAT   VSZ %MEM CPU %CPU COMMAND
  864     1 root     S     115m 84.9   1  1.8 /opt/bin/mediasrv -d --no-nodes
  860   857 root     S     141m104.7   1  1.5 /usr/bin/enigma2
 5864     1 root     S     115m 84.9   1  1.3 /opt/bin/mediasrv -d --no-nodes
   67     2 root     SW       0  0.0   0  0.7 [sched_high]
 
 5852  5849 root     R     2888  2.0   0  0.2 top
 
  863     1 root     S     115m 84.9   0  0.1 /opt/bin/mediasrv -d --no-nodes
    3     2 root     SW       0  0.0   0  0.1 [ksoftirqd/0]
  868   857 root     S     141m104.7   1  0.0 /usr/bin/enigma2
  898   857 root     S     141m104.7   1  0.0 /usr/bin/enigma2
  937   857 root     S N   141m104.7   0  0.0 /usr/bin/enigma2



[Sundtek]

The memory stats are somewhat bogus, normal endusers would never focus on virtual memory usage as this is allowed to exceed the physical memory size.

if possible check dmesg, and other vu+ related log files at that time.

Instead of a full reboot you might try on the telnet console

telnet 4
telnet 3

that might restart enigma and recover your situation.