Sundtek Support Forum
English => VU+ - VU Duo Settopbox => Thema gestartet von: Palinkat am Mai 04, 2011, 03:09:28 Nachmittag
-
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
-
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.
-
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
-
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.
-
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!!
-
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
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
-
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.
-
Ok, stats are pretty hebrew to me :)
This was from VU+ DUO
another capture with just rebooted & viewing T-channel
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
-
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.