18 replies to this topic

[limak]

hi everyone
thanks in advance for your help
i decided 2 days ago to use openpli with my vu+duo. everything worked fine for a while then i started experiencing slow zapping (so slow that the spinner shoiws for 2 seconds). i re installed the hole image but the problem persists.
the other problem is that the cam i use (mgcamd) does not work on some channels untill i restart it.
thanks again

Edited by limak, 4 March 2012 - 11:49.

[murtadha50]

I face the same problem in zapping, startup and mgcamd
Even after changing {A} to {B}

[mire]

I am refreshing this old subject. For some time now I have problems with slow zapping. When I restart enigma, everything works perfectly, and then after some time the receiver slows down completely, but it's most noticeable on zapping. It seems that changing frequency is slow. It's not about the cccam I am using, it's completely the same with FTA channels. When I change channel, transponder info on the skin doesn't show untill the channel is locked, and sometimes it takes a while.

It's behaving the same on both tuners (A: prime focus 180cm dish with vbox II, B: offset 120cm dish with diseqc positioner).

Updating doesn't help, and I don't really have many addons installed. Anyway, I am using the same addons for the last two years or so, and I have this problem in the last few months. Image is OpenPLi 2.1.

[spock]

You could try running enigma2 manually to see log output.

In terminal run telinit 4 to shut down enigma2. Then run it manually "/usr/bin/enigma2.sh" and you'll see the log. Keep the terminal window open on the computer until the problem occurs, then see what the log says when you're trying to zap (and post here).


I've seen similar things when I had a too big epg.. but it could be anything.

[mire]

Well... Let's try it. I zapped between 30-40 channels untill it slowed down. This is the log of the last zap which took a few seconds to lock to the transponder and displayed the rotating gears while waiting. Please help, if you can see something not right here. I can't.

playing 1:0:1:EF9:7D1:2:11A0000:0:0:0:
[eDVBCAService] free slot 0 demux 0 for service 1:0:19:EDF:7E0:2:11A0000:0:0:0:
[eDVBCAService] free service 1:0:19:EDF:7E0:2:11A0000:0:0:0:
user kill(SIGKILL) console App
pipes closed
decoder state: play, vpid=-1, apid=-1
DEMUX_STOP - pcr - ok
DEMUX_STOP - video - ok
VIDEO_STOP - ok
AUDIO_STOP - ok
DEMUX_STOP - audio - ok
AUDIO_CONTINUE - ok
DEMUX_STOP - ttx - ok
TuxTxt stopped service 907
cleaning up
TuxTxt cache cleared
start release channel timer
not pauseable.
RemovePopup, id = ZapError
[eDVBLocalTimerHandler] remove channel 0x72d58088
[eEPGCache] remove channel 0x72d58088
allocate channel.. 07d1:0002
(0)tune
RotorCmd 02, lastRotorCmd 02
prepare_sat System 1 Freq 11720000 Pol 0 SR 29500000 INV 2 FEC 3 orbpos 282 syst
em 1 modulation 0 pilot 2, rolloff 0
tuning to 1120 mhz
OURSTATE: tuning
allocate Channel: res 0
[eDVBCIInterfaces] addPMTHandler 1:0:1:EF9:7D1:2:11A0000:0:0:0:
allocate demux
[SEC] set static current limiting
[SEC] setVoltage 2
FE_ENABLE_HIGH_LNB_VOLTAGE: Operation not supported
[SEC] sleep 10ms
Connecting to ***.***.**.*** (***.***.**.**:****)
set sequence pos 3
[SEC] update current switch params
[SEC] startTuneTimeout 5000
[SEC] setFrontend 1
setting frontend 0
(0)fe event: status 0, inversion on, m_tuning 1
[SEC] sleep 500ms
(0)fe event: status 1f, inversion on, m_tuning 2
OURSTATE: ok
[eDVBLocalTimerHandler] channel 0x72d58088 running
[eEPGCache] channel 0x72d58088 running
stop release channel timer
[EPGC] next update in 2 sec
ok ... now we start!!
PATready
use pmtpid 0105 for service_id 0ef9
[SEC] set dynamic current limiting
eventNewProgramInfo 0 0
have 1 video stream(s) (0201), and 2 audio stream(s) (0281, 0295), and the pcr p
id is 0201, and the text pid is 0901
allocate demux
TuxTxt cache cleared
decoder state: play, vpid=513, apid=661
DMX_SET_PES_FILTER(0x201) - pcr - ok
DEMUX_START - pcr - ok
DMX_SET_PES_FILTER(0x295) - audio - ok
DEMUX_START - audio - ok
AUDIO_SET_BYPASS(0) - ok
AUDIO_PAUSE - ok
AUDIO_PLAY - ok
Video Device: /dev/dvb/adapter0/video0
demux device: /dev/dvb/adapter0/demux0
VIDEO_SET_STREAMTYPE 1 - ok
DMX_SET_PES_FILTER(0x201) - video - ok
DEMUX_START - video - ok
VIDEO_FREEZE - ok
VIDEO_PLAY - ok
DMX_SET_PES_FILTER(0x901) - ttx - ok
DEMUX_START - ttx - ok
TuxTxt cache cleared
TuxTxt: initialized
TuxTxt service started 901
TuxTxt running thread...(901)
VIDEO_SLOWMOTION(0) - ok
VIDEO_FAST_FORWARD(0) - ok
VIDEO_CONTINUE - ok
AUDIO_CONTINUE - ok
disable teletext subtitles
not pauseable.
[eDVBCAService] new service 1:0:1:EF9:7D1:2:11A0000:0:0:0:
[eDVBCAService] add demux 0 to slot 0 service 1:0:1:EF9:7D1:2:11A0000:0:0:0:
[eDVBCIInterfaces] gotPMT
demux 0 mask 01 prevhash 0
hdparm: HDIO_DRIVE_CMD: Invalid argument
sdt update done!
[EPGC] start caching events(1342354486)
[eDVBLocalTimerHandler] diff is -1
[eDVBLocalTimerHandler] diff < 120 .. use Transponder Time
[eDVBLocalTimerHandler] update RTC
[eDVBLocalTimerHandler] time update to 14:14:47
[eDVBLocalTimerHandler] m_time_difference is -1
[eDVBLocalTimerHandler] set Linux Time
[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(1342354492)
[EPGC] stop caching events(1342354492)
[EPGC] next update in 60 min

[metoo]

turn epg cache off ?

I thought epg cache is a PLI feature, other images dont have that, turn it off is faster?

Edited by metoo, 15 July 2012 - 13:31.

[pieterg]

The vuduo does not run very well with its latest driver releases (starting from linux 3.1).
We have an old 2.6.18 image online, many vuduo users stick to that version.

[spock]

Can't see much wrong in that log. You tried removing the epg to see it works better?

But as stated above I've read a lot of issues about vu duo and newer kernel.. perhaps it would be an idea to try running the old version.

[mire]

Do you suggest I should use the kernel from the last year, or just before the latest drivers? I am sure the problem existed before the latest drivers, but it never happened with the old kernel. New kernel also worked well for 4 or 5 months, and then this started...

[spock]

If you have had no problems with 3.1.1 kernel earlier, it might be the dvb-drivers.. or some commit to openpli lately (or skin, plugin).

You could try to just replace the drivers to some of the older ones and see if it helps (I think vuduo is the one labeled bm750);
http://archive.vuplu...wnload/drivers/

To update manually unpack the files (*.ko) and upload them to "/lib/modules/3.1.1/extra" with ftp and restart the box. Make sure you dont put dvb-drivers for old 2.6.18 kernel if you intend to run 3.1.1.

Also when this issue occurs, have you checked if you're running out of memory? (although this would most likely result in the box rebooting itself).

Edited by spock, 15 July 2012 - 19:23.

[mire]

Yes, I have checked the memory and it doesn't seem to be the problem. I even tried GlassHD feature to clear unused parts of memory every 3 minutes, but it didn't change anything. I have about 23-25 MB free all the time.

I will try to install older drivers and report if it has helped, thank you for suggestion.

[spock]

From what I've read on the forums here earlier, devs and users earlier reported issues with glass hd skin/utils, even after uninstalling it (apparently it makes changes to the system files). Although a bit tedious, if nothing else helps - perhaps you could try a clean flash using standard openpli skin? (making sure glasshd skin/utils dont get installed either manually or from autobackup).

[mire]

I know about the GlassHD problems. Actually, I have experienced them before. I am now sure that GlassHD is not the reason, because the problem started before the installation, and it was a completely clean installation.

But, I have to change something I have written before. It seems that memory is the source of the problem. Yesterday my Vu+ was very very slow and free memory was only 2 MB! GlassHD tried to clean it, but managed only to free about 2 MB more. After enigma restart, I had about 30 MB free, and everything was working well.

So, I definitely have a memory leak. How can I identify what is the cause?

[Rob van der Does]

It has been on this forum many times before: under Linux 'free memory' is memory waisted. Linux tries to use (almost) all that is available.
A better criterion would be 'readily available memory', which is (when you telnet 'free') the sum of free, shared & buffered.

Why would you want to have 'free' memory?

[mire]

I don't. I am not a Linux connoseur. I just want my receiver to zap as fast as it used to.

[cisarp]

Hello
I seem to have a similar problem on my DM7025 running enigma2.
I noticed that when playing mp3 music, the time comes when the box becomes very slow.
I watched the RSS value of enigma2 with top and I noticed that it grows by 1MB with every 1-2 mp3 played.
So I wonder whether there is not a memory leak related to switching of services in enimgma2.
I searched the forum and found some ideas that epg could be suspect, but I suppose that mp3 shouldn't affect the EPG data.
When I restart enimgma, the memory is freed and when it comes up again, it behaves normally, so it is clear that the memory is really occupied by enigma.
I can provide more information if someone could look at this issue.
BR
Petr

[mire]

Why not, I still hope someone can help. I didn't solve my problem.

[razorback]

Yesterday I flashed OpenPLi 3.0 (Kernel 3.1.1) on to my VU+Duo and there is no issue whatsoever in terms of zapping speed.
Its lightning fast and works like a charm.

R

[mire]

I installed 3.0 too, but unfortunately it didn't help. It's behaving pretty much the same.