View Full Version : Constant Spinners and hanging
Folks,
I'm hoping someone can shed some light on this for me as I'm at my wits end.
My Vu Duo+ is suffering constant spinners, even just watching TV it will become unresponsive and spinning VIX for 20+ minutes.
It is an original box, @2 and half years old.
My Setup is as follows, Vu Duo with EPG, PTS, Picons and Swap file all on a 16gb USB key.
The box is becoming painful to use, I have tried reflashing with latest VIX, not restoring backup and currently i am using .679 as it seems most stable in my current situation.
I'm also having issues with the network service not starting. I need to go into menu>setup>network and select restart network when I reboot the box, this is an intermittent issue however.
I have attached a copy of the ''Top'' output in case that throws up any pointers for those more in the know than myself.
Thanks in advance folks.
Mem: 126824K used, 11556K free, 0K shrd, 428K buff, 16320K cached
Mem: 126128K used, 12252K free, 0K shrd, 352K buff, 8952K cached
CPU: 9% usr 54% sys 0% nic 9% idle 18% io 0% irq 9% sirq
Load average: 0.98 0.56 0.49 2/165 2914
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
1 0 root S 1916 1% 0% init [3]
2 0 root SW 0 0% 0% [kthreadd]
3 2 root SW 0 0% 0% [ksoftirqd/0]
5 2 root SW 0 0% 0% [kworker/u:0]
6 2 root SW 0 0% 0% [migration/0]
7 2 root SW 0 0% 0% [migration/1]
9 2 root SW 0 0% 0% [ksoftirqd/1]
11 2 root SW< 0 0% 0% [khelper]
12 2 root SW 0 0% 0% [kdevtmpfs]
13 2 root SW 0 0% 0% [sync_supers]
14 2 root SW 0 0% 0% [bdi-default]
15 2 root SW< 0 0% 0% [kblockd]
16 2 root SW< 0 0% 0% [ata_sff]
17 2 root SW 0 0% 0% [khubd]
18 2 root SW< 0 0% 0% [cfg80211]
19 2 root SW< 0 0% 0% [rpciod]
20 2 root DW 0 0% 0% [kswapd0]
21 2 root SW 0 0% 0% [fsnotify_mark]
22 2 root SW< 0 0% 0% [nfsiod]
23 2 root SW< 0 0% 0% [crypto]
33 2 root SW 0 0% 0% [scsi_eh_0]
34 2 root SW 0 0% 0% [scsi_eh_1]
35 2 root SW 0 0% 0% [kworker/u:1]
37 2 root SW 0 0% 0% [mtdblock0]
38 2 root SW 0 0% 0% [mtdblock1]
39 2 root SW 0 0% 0% [scsi_eh_2]
40 2 root SW 0 0% 9% [usb-storage]
41 2 root SW 0 0% 0% [mtdblock2]
42 2 root SW 0 0% 0% [mtdblock3]
43 2 root SW 0 0% 0% [mtdblock4]
44 2 root SW 0 0% 0% [mtdblock5]
45 2 root SW 0 0% 0% [mtdblock6]
47 2 root SW 0 0% 0% [kworker/1:1]
48 2 root SW 0 0% 0% [ubi_bgt0d]
49 2 root SW 0 0% 0% [ubifs_bgt0_0]
53 2 root SW 0 0% 0% [kworker/0:2]
96 2 root SW 0 0% 0% [kworker/1:2]
98 2 root SW 0 0% 0% [jbd2/sda1-8]
99 2 root SW< 0 0% 0% [ext4-dio-unwrit]
122 2 root SW 0 0% 0% [jbd2/sdb1-8]
123 2 root SW< 0 0% 0% [ext4-dio-unwrit]
133 2 root SW 0 0% 0% [flush-8:16]
135 2 root SW 0 0% 0% [sched]
136 2 root RW 0 0% 0% [sched_low]
137 2 root RW 0 0% 0% [sched_high]
138 2 root SW 0 0% 0% [sched_idle]
156 2 root SW 0 0% 0% [brcmv]
160 2 root SW 0 0% 0% [fbt0]
173 2 root SW 0 0% 0% [lcd]
181 2 root SW 0 0% 0% [sc0]
183 2 root SW 0 0% 0% [sc1]
379 1 root S 4016 3% 0% nmbd -D
381 1 root S 7124 5% 0% smbd -D
402 381 root S 7124 5% 0% smbd -D
412 1 daemon S 1996 1% 0% /sbin/portmap
432 1 messageb S 3048 2% 0% /usr/bin/dbus-daemon --system
436 1 root S 2664 2% 0% /usr/sbin/dropbear -r /etc/dropbear/dr
root@vuduo:~#
Rob van der Does
22-10-13, 16:29
You say to be using build 679; you really should flash build 762.
You say to be using build 679; you really should flash build 762.
Hi Rob,
I also said
I have tried reflashing with latest VIX, not restoring backup I am using .679 as currently that is the only build that gives me any stability at all and even at that it is churning slowly to halt every hour or so.
I'm seriously at a loss as to what the issue is, unless maybe its a hardware fault? Maybe the flash is on the way out?
Is there anyway to test the flash integrity?
I just rebooted the box now and it took over 11 minutes to boot after a prolonged hang at the VIX ''loading'' screen
Rob van der Does
22-10-13, 16:42
Using an old build that doesn't hold a lot of bugfixes won't help you.
It's very well possible that your box will be suffering from the Elco-problem. Try to replace that: it must be done sometime anyway.
I understand what you mean regarding bugfixes, and ideally I would update to the latest build but the lack of stability on my box currently quickly renders it unusable so to keep some viewing I reverted to the older build.
What is ''Elco problem''? Is that the capacitor issue?
Thanks for the help by the way.
Rob van der Does
22-10-13, 16:49
What is ''Elco problem''? Is that the capacitor issue?
yep. And it really looks like it. If so, using the box will make things worse and lead to damage to the voltage regulator.
yep. And it really looks like it. If so, using the box will make things worse and lead to damage to the voltage regulator.
Well I actually have a spare PSU here so I will swap that out and see how it goes, hopefully it will sort the issue for me.
Rob van der Does
22-10-13, 17:03
tbh I don't know if the culprit cap is on the PSU? But I thought it is one on the MB.
You must look that up in the thread about that.
Well I swapped the C807 capacitor and still the Issue persists :(
It took @11 minutes for the box to boot and there seems to be no real improvement.
Is this symptomatic of failing flash?
If it is, is it possible to buy a new MB? and approximate price?
Hi banie01
Some Duos suffer from a memory leak, not sure as mine doesn't. There is a plugin "cache flush plugin" which I think is on the feeds and might help you.
Also try turning PTS off and see if that makes a difference.
Hope this helps.
micscave
Rob van der Does
23-10-13, 14:33
That has nothing to do with booting.
Rob van der Does
23-10-13, 14:35
Well I swapped the C807 capacitor and still the Issue persists :(
It took @11 minutes for the box to boot and there seems to be no real improvement.
Is this symptomatic of failing flash?
If it is, is it possible to buy a new MB? and approximate price?
Do you have an internal HDD? If so: disconnect it and see how the box works then.
Explanation: if the journal tells Linux there are or could be issues, an HDD-check will be carried out during the bootprocess. And that can easily take 10 minutes.
That has nothing to do with booting.
Hi Rob
He does say in his first post that it happens when he is just watching TV also, so I think my post was relevant.
Miscave, thanks for the tip re: cacheflush I have been running that plugin for quite a while now.
I've hopefully got my own box sorted now!
I replaced the c807 capacitor with no joy, so I replaced the 2 adjacent caps aswell
Regarding the slow startup and it possibly being a HD issue, with my internal drive disconnected the startup from cold/deep standby was still very slow.
So I also deleted my network mounts and I'm happy to report that while boot from cold is still quite slow....it is faster
The box itself is running sweet as a nut again once the long boot completes!
tbh I don't know if the culprit cap is on the PSU? But I thought it is one on the MB.
You must look that up in the thread about that.
That tread is here http://www.world-of-satellite.com/showthread.php?26743-Dead-Vu-Duo-repair-guide
Hi
I upgraded from OpenVIX 2.x today because I suffered from the full rootfs issue
root@vuduo:/# df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 102.0M 102.0M 12.0K 100% /
tmpfs 64.0K 4.0K 60.0K 6% /dev
/dev/sdb1 3.7G 27.3M 3.7G 1% /media/usb
tmpfs 67.5M 760.0K 66.8M 1% /var/volatile
/dev/sda1 1.8T 1.2T 608.6G 67% /media/hdd
root@vuduo:/#
and I upgraded to 3.0.339 and once I got it up and running again I suffered the constant spinner when I used the "prev" button to swap between two channels. The spinner won't go away and I can't do anything from the remote control. The interface on the unit still works so I rebooted it from there after a few checks posted below.
I'm downloading 3.0.796 right now to check if it helps.
The constant spinner/hang accrued around 19:30 in the logs
Welcome to OpenViX for vuduo
openvix 3.0 vuduo
vuduo login: root
root@vuduo:~# df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 102.0M 49.2M 52.9M 48% /
devtmpfs 67.5M 4.0K 67.4M 0% /dev
tmpfs 64.0K 0 64.0K 0% /media
/dev/sda1 1.8T 1.2T 608.6G 67% /media/hdd
tmpfs 67.6M 1.1M 66.5M 2% /var/volatile
/dev/sdb1 3.7G 33.0M 3.7G 1% /media/usb
root@vuduo:~# dmesg
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:>>close_mpod tuner:0
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:remux stop
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:get_remux_startcnt() count : 0
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:get_remux_startcnt() count : 0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_STOP 1 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_STOP 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_CONTINUE 1 0 audio pid_hndl : 0x0
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_CONTINUE:bcm7335->audio_pid_hndl is null 0 0
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:>>bm750_enable_ci_buffer 0 1
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:get_remux_startcnt() count : 1
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:NEXUS_Remux_Start
Dec 6 19:30:30 vuduo user.warn kernel: FE tune
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_SET_BYPASS_MODE 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: proc_get_ac3 1 audio_passthrough_spdif : 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_PAUSE 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_PLAY 1 decoder start : 0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_SET_STREAMTYPE 0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_FREEZE 1 0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_PLAY 1 2 2
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_SLOWMOTION 0 1
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_FAST_FORWARD 0 1
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_CONTINUE 1 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_CONTINUE 1 1 audio pid_hndl : 0xc0ad58ec
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: setting mute : 0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_GET_SIZE src w: 0 h:0 display w:0 h:0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_GET_SIZE aspect: 1 0
Dec 6 19:33:45 vuduo authpriv.notice login[14335]: ROOT LOGIN on '/dev/pts/0' from '192.168.2.2:3302'
root@vuduo:~# date
Fri Dec 6 19:38:59 GMT 2013
root@vuduo:~# top
Mem: 107216K used, 31164K free, 0K shrd, 15704K buff, 13912K cached
CPU: 52% usr 8% sys 4% nic 30% idle 0% io 0% irq 4% sirq
Load average: 1.47 1.34 0.89 2/87 14343
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
449 444 root R 116m 86% 52% /usr/bin/enigma2
14343 14335 root R 2664 2% 4% top
489 1 root S 14348 10% 0% /usr/softcams/CCcam.2.3.0
338 1 avahi S 3692 3% 0% avahi-daemon: running [vuduo.local]
339 338 avahi S 3692 3% 0% avahi-daemon: chroot helper
315 1 messageb S 3048 2% 0% /usr/bin/dbus-daemon --system
326 1 root S 3040 2% 0% /usr/sbin/inetd
14334 326 root S 2992 2% 0% telnetd
14335 14334 root S 2988 2% 0% -sh
331 1 root S 2664 2% 0% /sbin/klogd -n
329 1 root S 2664 2% 0% /sbin/syslogd -n -O /var/log/messages
319 1 root S 2664 2% 0% /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 22
444 1 root S 2664 2% 0% {enigma2.sh} /bin/sh /usr/bin/enigma2.sh
1 0 root S 1916 1% 0% init [3]
112 2 root SW 0 0% 0% [sched_high]
3 2 root SW 0 0% 0% [ksoftirqd/0]
534 2 root SW 0 0% 0% [kdvb-ad-0-fe-0]
111 2 root SW 0 0% 0% [sched_low]
97 2 root SW 0 0% 0% [jbd2/sda1-8]
71 2 root SW 0 0% 0% [kworker/1:2]
350 2 root SW 0 0% 0% [ci_kthread]
349 2 root SW 0 0% 0% [ca:0:4]
5 2 root SW 0 0% 0% [kworker/u:0]
8 2 root SW 0 0% 0% [kworker/1:0]
45 2 root SW 0 0% 0% [ubi_bgt0d]
21 2 root SW 0 0% 0% [kswapd0]
547 2 root SW 0 0% 0% [usb-storage]
44 2 root SW 0 0% 0% [mtdblock6]
14300 2 root SW 0 0% 0% [kworker/0:0]
148 2 root SW 0 0% 0% [lcd]
38 2 root SW 0 0% 0% [mtdblock0]
39 2 root SW 0 0% 0% [mtdblock1]
40 2 root SW 0 0% 0% [mtdblock2]
41 2 root SW 0 0% 0% [mtdblock3]
42 2 root SW 0 0% 0% [mtdblock4]
43 2 root SW 0 0% 0% [mtdblock5]
46 2 root SW 0 0% 0% [ubifs_bgt0_0]
113 2 root SW 0 0% 0% [sched_idle]
35 2 root SW 0 0% 0% [scsi_eh_1]
2 0 root SW 0 0% 0% [kthreadd]
12 2 root SW 0 0% 0% [kdevtmpfs]
17 2 root SW 0 0% 0% [khubd]
36 2 root SW 0 0% 0% [kworker/u:1]
135 2 root SW 0 0% 0% [fbt0]
6 2 root SW 0 0% 0% [migration/0]
7 2 root SW 0 0% 0% [migration/1]
9 2 root SW 0 0% 0% [ksoftirqd/1]
11 2 root SW< 0 0% 0% [khelper]
13 2 root SW 0 0% 0% [sync_supers]
14 2 root SW 0 0% 0% [bdi-default]
15 2 root SW< 0 0% 0% [kblockd]
16 2 root SW< 0 0% 0% [ata_sff]
18 2 root SW< 0 0% 0% [cfg80211]
20 2 root SW< 0 0% 0% [rpciod]
22 2 root SW 0 0% 0% [fsnotify_mark]
23 2 root SW< 0 0% 0% [nfsiod]
24 2 root SW< 0 0% 0% [crypto]
34 2 root SW 0 0% 0% [scsi_eh_0]
98 2 root SW< 0 0% 0% [ext4-dio-unwrit]
110 2 root SW 0 0% 0% [sched]
131 2 root SW 0 0% 0% [brcmv]
156 2 root SW 0 0% 0% [sc0]
root@vuduo:~#
root@vuduo:~# reboot
Broadcast message from root@vuduo (pts/0) (Fri Dec 6 19:50:57 2013):
The system is going down for reboot NOW!
root@vuduo:~#
Welcome to OpenViX for vuduo
openvix 3.0 vuduo
vuduo login: root
root@vuduo:~# df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 102.0M 47.3M 54.7M 46% /
devtmpfs 67.5M 4.0K 67.4M 0% /dev
tmpfs 64.0K 0 64.0K 0% /media
/dev/sda1 1.8T 1.2T 608.6G 67% /media/hdd
/dev/sdb1 3.7G 33.0M 3.7G 1% /media/usb
tmpfs 67.6M 452.0K 67.1M 1% /var/volatile
root@vuduo:~#
Upgraded to 3.0.796 but the problem occurred immediate again
After the upgrade I just altered some minor settings, time, OSD etc.
Then I watched the Channel TV4 HD, changed to TV4 (Swedish channels on 0.8 West) I did it a couple of minutes past 22:00
Will leave it on for more then 30mins before rebooting to see if it will be released
The top shows over 100% usage for enigma2
top - 22:18:40 up 28 min, 1 user, load average: 1.16, 1.23, 0.82
Tasks: 68 total, 2 running, 66 sleeping, 0 stopped, 0 zombie
Cpu(s): 51.5%us, 2.0%sy, 1.5%ni, 43.9%id, 0.0%wa, 0.0%hi, 1.1%si, 0.0%st
Mem: 138380k total, 110524k used, 27856k free, 1612k buffers
Swap: 0k total, 0k used, 0k free, 43356k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
522 root 20 0 93328 45m 9892 R 105 33.5 14:34.80 enigma2
107 root 20 0 0 0 0 S 3 0.0 0:57.88 sched_high
604 root 20 0 13328 2864 1752 S 2 2.1 0:32.22 CCcam.2.3.0
1463 root 20 0 2704 1152 944 R 2 0.8 0:00.24 top
1 root 20 0 1916 640 564 S 0 0.5 0:02.10 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0 0.0 0:00.67 ksoftirqd/0
/home/root is empty
root@vuduo:~# df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 102.0M 51.3M 50.7M 50% /
devtmpfs 67.5M 4.0K 67.4M 0% /dev
tmpfs 64.0K 0 64.0K 0% /media
/dev/sda1 1.8T 1.2T 608.9G 67% /media/hdd
tmpfs 67.6M 96.0K 67.5M 0% /var/volatile
root@vuduo:~# free
total used free shared buffers cached
Mem: 138380 109872 28508 0 1612 43356
-/+ buffers/cache: 64904 73476
Swap: 0 0 0
root@vuduo:~# date
Fri Dec 6 22:25:39 CET 2013
root@vuduo:~#
Leaving it on didn't help, rebooting it
root@vuduo:~# df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 102.0M 51.3M 50.7M 50% /
devtmpfs 67.5M 4.0K 67.4M 0% /dev
tmpfs 64.0K 0 64.0K 0% /media
/dev/sda1 1.8T 1.2T 608.9G 67% /media/hdd
tmpfs 67.6M 96.0K 67.5M 0% /var/volatile
root@vuduo:~# free
total used free shared buffers cached
Mem: 138380 109984 28396 0 1612 43388
-/+ buffers/cache: 64984 73396
Swap: 0 0 0
root@vuduo:~# top
top - 22:43:20 up 53 min, 1 user, load average: 1.26, 1.25, 1.17
Tasks: 66 total, 2 running, 64 sleeping, 0 stopped, 0 zombie
Cpu(s): 36.0%us, 2.9%sy, 1.5%ni, 57.1%id, 0.3%wa, 0.0%hi, 2.1%si, 0.0%st
Mem: 138380k total, 110096k used, 28284k free, 1612k buffers
Swap: 0k total, 0k used, 0k free, 43388k cached
Unknown command - try 'h' for help
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
522 root 20 0 94352 45m 9892 R 104 33.5 40:21.83 enigma2
107 root 20 0 0 0 0 S 4 0.0 1:50.80 sched_high
2223 root 20 0 2640 1044 840 R 4 0.8 0:00.06 top
root@vuduo:~# date
Fri Dec 6 22:43:27 CET 2013
root@vuduo:~#
Will continue to test the image but hints are welcome
N.B. I haven't exchanged any capacitor but I don't see how that can be related to this issue that appeared today when I applied the 3.0 version, but I will exchange them later on.
That tread is here http://www.world-of-satellite.com/showthread.php?26743-Dead-Vu-Duo-repair-guide
Hi
I upgraded from OpenVIX 2.x today because I suffered from the full rootfs issue
root@vuduo:/# df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 102.0M 102.0M 12.0K 100% /
tmpfs 64.0K 4.0K 60.0K 6% /dev
/dev/sdb1 3.7G 27.3M 3.7G 1% /media/usb
tmpfs 67.5M 760.0K 66.8M 1% /var/volatile
/dev/sda1 1.8T 1.2T 608.6G 67% /media/hdd
root@vuduo:/#
and I upgraded to 3.0.339 and once I got it up and running again I suffered the constant spinner when I used the "prev" button to swap between two channels. The spinner won't go away and I can't do anything from the remote control. The interface on the unit still works so I rebooted it from there after a few checks posted below.
I'm downloading 3.0.796 right now to check if it helps.
The constant spinner/hang accrued around 19:30 in the logs
Welcome to OpenViX for vuduo
openvix 3.0 vuduo
vuduo login: root
root@vuduo:~# df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 102.0M 49.2M 52.9M 48% /
devtmpfs 67.5M 4.0K 67.4M 0% /dev
tmpfs 64.0K 0 64.0K 0% /media
/dev/sda1 1.8T 1.2T 608.6G 67% /media/hdd
tmpfs 67.6M 1.1M 66.5M 2% /var/volatile
/dev/sdb1 3.7G 33.0M 3.7G 1% /media/usb
root@vuduo:~# dmesg
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:>>close_mpod tuner:0
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:remux stop
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:get_remux_startcnt() count : 0
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:get_remux_startcnt() count : 0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_STOP 1 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_STOP 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_CONTINUE 1 0 audio pid_hndl : 0x0
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_CONTINUE:bcm7335->audio_pid_hndl is null 0 0
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:>>bm750_enable_ci_buffer 0 1
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:get_remux_startcnt() count : 1
Dec 6 19:30:30 vuduo user.warn kernel: [CI]:NEXUS_Remux_Start
Dec 6 19:30:30 vuduo user.warn kernel: FE tune
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_SET_BYPASS_MODE 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: proc_get_ac3 1 audio_passthrough_spdif : 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_PAUSE 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_PLAY 1 decoder start : 0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_SET_STREAMTYPE 0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_FREEZE 1 0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_PLAY 1 2 2
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_SLOWMOTION 0 1
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_FAST_FORWARD 0 1
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_CONTINUE 1 1
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: AUDIO_CONTINUE 1 1 audio pid_hndl : 0xc0ad58ec
Dec 6 19:30:30 vuduo user.warn kernel: [AUD]: setting mute : 0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_GET_SIZE src w: 0 h:0 display w:0 h:0
Dec 6 19:30:30 vuduo user.warn kernel: [VID]: VIDEO_GET_SIZE aspect: 1 0
Dec 6 19:33:45 vuduo authpriv.notice login[14335]: ROOT LOGIN on '/dev/pts/0' from '192.168.2.2:3302'
root@vuduo:~# date
Fri Dec 6 19:38:59 GMT 2013
root@vuduo:~# top
Mem: 107216K used, 31164K free, 0K shrd, 15704K buff, 13912K cached
CPU: 52% usr 8% sys 4% nic 30% idle 0% io 0% irq 4% sirq
Load average: 1.47 1.34 0.89 2/87 14343
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
449 444 root R 116m 86% 52% /usr/bin/enigma2
14343 14335 root R 2664 2% 4% top
489 1 root S 14348 10% 0% /usr/softcams/CCcam.2.3.0
338 1 avahi S 3692 3% 0% avahi-daemon: running [vuduo.local]
339 338 avahi S 3692 3% 0% avahi-daemon: chroot helper
315 1 messageb S 3048 2% 0% /usr/bin/dbus-daemon --system
326 1 root S 3040 2% 0% /usr/sbin/inetd
14334 326 root S 2992 2% 0% telnetd
14335 14334 root S 2988 2% 0% -sh
331 1 root S 2664 2% 0% /sbin/klogd -n
329 1 root S 2664 2% 0% /sbin/syslogd -n -O /var/log/messages
319 1 root S 2664 2% 0% /usr/sbin/dropbear -r /etc/dropbear/dropbear_rsa_host_key -p 22
444 1 root S 2664 2% 0% {enigma2.sh} /bin/sh /usr/bin/enigma2.sh
1 0 root S 1916 1% 0% init [3]
112 2 root SW 0 0% 0% [sched_high]
3 2 root SW 0 0% 0% [ksoftirqd/0]
534 2 root SW 0 0% 0% [kdvb-ad-0-fe-0]
111 2 root SW 0 0% 0% [sched_low]
97 2 root SW 0 0% 0% [jbd2/sda1-8]
71 2 root SW 0 0% 0% [kworker/1:2]
350 2 root SW 0 0% 0% [ci_kthread]
349 2 root SW 0 0% 0% [ca:0:4]
5 2 root SW 0 0% 0% [kworker/u:0]
8 2 root SW 0 0% 0% [kworker/1:0]
45 2 root SW 0 0% 0% [ubi_bgt0d]
21 2 root SW 0 0% 0% [kswapd0]
547 2 root SW 0 0% 0% [usb-storage]
44 2 root SW 0 0% 0% [mtdblock6]
14300 2 root SW 0 0% 0% [kworker/0:0]
148 2 root SW 0 0% 0% [lcd]
38 2 root SW 0 0% 0% [mtdblock0]
39 2 root SW 0 0% 0% [mtdblock1]
40 2 root SW 0 0% 0% [mtdblock2]
41 2 root SW 0 0% 0% [mtdblock3]
42 2 root SW 0 0% 0% [mtdblock4]
43 2 root SW 0 0% 0% [mtdblock5]
46 2 root SW 0 0% 0% [ubifs_bgt0_0]
113 2 root SW 0 0% 0% [sched_idle]
35 2 root SW 0 0% 0% [scsi_eh_1]
2 0 root SW 0 0% 0% [kthreadd]
12 2 root SW 0 0% 0% [kdevtmpfs]
17 2 root SW 0 0% 0% [khubd]
36 2 root SW 0 0% 0% [kworker/u:1]
135 2 root SW 0 0% 0% [fbt0]
6 2 root SW 0 0% 0% [migration/0]
7 2 root SW 0 0% 0% [migration/1]
9 2 root SW 0 0% 0% [ksoftirqd/1]
11 2 root SW< 0 0% 0% [khelper]
13 2 root SW 0 0% 0% [sync_supers]
14 2 root SW 0 0% 0% [bdi-default]
15 2 root SW< 0 0% 0% [kblockd]
16 2 root SW< 0 0% 0% [ata_sff]
18 2 root SW< 0 0% 0% [cfg80211]
20 2 root SW< 0 0% 0% [rpciod]
22 2 root SW 0 0% 0% [fsnotify_mark]
23 2 root SW< 0 0% 0% [nfsiod]
24 2 root SW< 0 0% 0% [crypto]
34 2 root SW 0 0% 0% [scsi_eh_0]
98 2 root SW< 0 0% 0% [ext4-dio-unwrit]
110 2 root SW 0 0% 0% [sched]
131 2 root SW 0 0% 0% [brcmv]
156 2 root SW 0 0% 0% [sc0]
root@vuduo:~#
root@vuduo:~# reboot
Broadcast message from root@vuduo (pts/0) (Fri Dec 6 19:50:57 2013):
The system is going down for reboot NOW!
root@vuduo:~#
Welcome to OpenViX for vuduo
openvix 3.0 vuduo
vuduo login: root
root@vuduo:~# df -h
Filesystem Size Used Available Use% Mounted on
ubi0:rootfs 102.0M 47.3M 54.7M 46% /
devtmpfs 67.5M 4.0K 67.4M 0% /dev
tmpfs 64.0K 0 64.0K 0% /media
/dev/sda1 1.8T 1.2T 608.6G 67% /media/hdd
/dev/sdb1 3.7G 33.0M 3.7G 1% /media/usb
tmpfs 67.6M 452.0K 67.1M 1% /var/volatile
root@vuduo:~#
some Duo's are known to suffer memory leak issues with Kernel 3.1.1 based images try a older kernel 2.6.18 image or try the cache flush plugin.
Did a final test for the day:
Configured the <> buttons to change channel instead of showing a menu of recent channels and used it for swapping between 2 channels, It works fine.
But as soon as I press the "prev" on my Harmony remote or 0 on the Vu remote, the spinner pops up and I can't do anything more.
And to make it clear, the receiver works so I can watch the program but with the spinner in the upper left hand corner.
In the older version of OpenVIX there was a setting for the 0 button called panic that could be configured to swap back to the first channel instead of previous channel but I can't find that setting any more, have I gone blind or is it removed?
In the older version of OpenVIX there was a setting for the 0 button called panic that could be configured to swap back to the first channel instead of previous channel but I can't find that setting any more, have I gone blind or is it removed?
Menu -> Setup -> System -> Channel selection settings -> Enable panic button
some Duo's are known to suffer memory leak issues with Kernel 3.1.1 based images try a older kernel 2.6.18 image or try the cache flush plugin.
Thanks for that reply. But I'm quite curious how the hardware can suffer a memory leak, it's usually a software issue?
But I will listen to your advice and try the recommended version. But I'll start with the cache flush plugin.
Two questions though:
1) Where do I find a version using kernel 2.6.18? Which version shall I pick
2) Before the upgrade from 2.x to 3.0 I had big issues watching HD channels which I thought was related to poor alignment or similar of my dish but when upgrading to 3.0 they all work perfect! Will I loose them if I downgrade? i.e is there any fix applied to handle HD channels better?
While searching the forum for older images I stumbled upon this tread (http://www.world-of-satellite.com/showthread.php?32657-Clear-Zap-History-Vix-latest-builds) since I couldn't find where to enable 0 as the panic button and I checked it, it was enabled (I guess it's by default) to be panic button so I changed it and it solved the issue!!
And as you probably can see in my posts I re-installed the tuner today and haven't configured or restored any Favourite Bouquets yet, which may be contribution to the fact the it can't find the first channel in a empty list.
Thanks anyway pheonix for your input :thumbsup:, much appreciated at this late hour
I think my case can be closed for now and I can give the feed-back I have after a few hours with the 3.0 image that I like it a lot and I will recommend my friends to do the upgrade too.
I have been waiting so long since I'm a software test engineer testing our own developed routers/switches based on Linux and for the Vu+Duo I have been following my golden rule "If it ain't broken, Don't try to fix it"
Thanks for that reply. But I'm quite curious how the hardware can suffer a memory leak, it's usually a software issue?
But I will listen to your advice and try the recommended version. But I'll start with the cache flush plugin.
Two questions though:
1) Where do I find a version using kernel 2.6.18? Which version shall I pick
2) Before the upgrade from 2.x to 3.0 I had big issues watching HD channels which I thought was related to poor alignment or similar of my dish but when upgrading to 3.0 they all work perfect! Will I loose them if I downgrade? i.e is there any fix applied to handle HD channels better?
While searching the forum for older images I stumbled upon this tread (http://www.world-of-satellite.com/showthread.php?32657-Clear-Zap-History-Vix-latest-builds) since I couldn't find where to enable 0 as the panic button and I checked it, it was enabled (I guess it's by default) to be panic button so I changed it and it solved the issue!!
And as you probably can see in my posts I re-installed the tuner today and haven't configured or restored any Favourite Bouquets yet, which may be contribution to the fact the it can't find the first channel in a empty list.
Thanks anyway pheonix for your input :thumbsup:, much appreciated at this late hour
I think my case can be closed for now and I can give the feed-back I have after a few hours with the 3.0 image that I like it a lot and I will recommend my friends to do the upgrade too.
I have been waiting so long since I'm a software test engineer testing our own developed routers/switches based on Linux and for the Vu+Duo I have been following my golden rule "If it ain't broken, Don't try to fix it"
Im no expert but from my understanding the memory leak is directly associated with the 3.1.1 linux kernel on the Duo, it does not appear with the earlier 2.6.18 kernel.
Debug logs might help someone spot the issue here too.
Menu -> Setup -> System -> Logs -> Settings -> Enable debug log = yes.
Enable them, restart E2 & upload one the next time this happens.
Im no expert but from my understanding the memory leak is directly associated with the 3.1.1 linux kernel on the Duo, it does not appear with the earlier 2.6.18 kernel.
OK, Then it make sense. I'm familiar with leaks in the Linux kernel and and we do a lot of fixes for them ;-)
The "some Duo's are known to suffer memory leak issues" must be related to if there are any FPGA code or chip sets being different since the kernel has drivers for them all but often they are not 100% tested.
But I haven't seen any way to read out the system information with versions of everything.
Thanks again to all who contributed
Debug logs might help someone spot the issue here too.
Menu -> Setup -> System -> Logs -> Settings -> Enable debug log = yes.
Enable them, restart E2 & upload one the next time this happens.
I did change the setting to the 0/panic button again to create a constant spinner hang with the debug log enabled.
I hope it can contribute to solving the issue for others.
What EPG sources are you using?
Not really sure, I played with it years ago and haven't changed since
In the extension menu (blue button) and in the plugin meny I have the CrossEPG downloader
Before the upgrade I had one more (but I don't know it it was in use) I think it was something like Rytec Sweden XMLTV
Is this the reason for asking? from my log
[EPGC] abort non avail schedule reading
[EPGC] abort non avail schedule other reading
[EPGC] abort non avail netmed schedule reading
[EPGC] abort non avail netmed schedule other reading
[EPGC] abort non avail FreeSat schedule_other reading
[EPGC] abort non avail viasat reading
[EPGC] nownext finished(1386370592)
[EPGC] stop caching events(1386370592)
[EPGC] next update in 60 min
KEY: 11 0
main thread is non-idle! display spinner!
If you set the box up again from scratch, surely you should know what EPG sources you are enabling?
Haven't configured any today, so the answer will then be none I guess
I also applying the upgrade 796 just now before going to bed watching my new Nat Geo Wild HD
See you later
I located in Sweden so I'm h1 hour ahead of you I guess
Since banie01 has been a member equally long as me, perhaps his box of the same age as mine and the above bay be useful.
I bought it in July 2010 and the text printed on the MB say V2.3 2010-04-02.
If you set the box up again from scratch, surely you should know what EPG sources you are enabling?
I have now read Sicilian guide http://www.world-of-satellite.com/showthread.php?14373-How-to-setup-Crossepg-in-all-ViX-Images and selected Rytec Sweden XMLTV EPG if that's the answer you did expect.
Learning new things every day :-) Thanks guys for kicking my butt in the ring direction
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.