"No free tuner" message every morning after power up from normal standby

[white_westie]

Getting "No free tuner" message every morning when powerup from normal standby.

Only loaded Apollo 165 last week, and problem has occured every morning once I scheduled daily epg downloads.

Background
Have been running et4x00 for the last 2 years on OpenVix 3.666 (no laughing!!!)
Only upgraded last week to latest version to get fixes for recent problems with XMLTV-Importer

Did a clean flash to Apollo 165 and then updated online to Apollo 166.

Setup as follows:
Sat Feed: T90 dish with 5W,13E,19E,28E feeds to a 4 way disecq switch
Network: wired with static IP
USB storage: 8GB pendrive (rear slot) used for epg, logs, timeshift and 32MB swap
HDD storage: NFS mounted drive from 2nd stb et9x00
Extra plugins: OnDemand from feeds
Skin: default
EPG: CrossEPG runs daily at 05:25, sources are OpenTV on 28E and 13E
XMLTV-Importer runs daily at 05:45, sources are Rytec France and Germany/Austria/Swiss


Have to restart gui to clear tuning error, and kill crossepg processes to allow next epg download to run, or just restart stb.

Once tuner is working okay, have no trouble watching tv and channel hopping between sats.
Suspect it's to with daily epg download, as it's the only thing that runs during the night.

Did some debugging and noticed that every time it happens the scheduled background crossepg downloader does not complete.
However the scheduled XMLTV-Importer runs okay 20mins later and seems to complete.


root 555 431 0 05:25 ? 00:00:00 /bin/sh -c /usr/crossepg/crossepg_downloader -r -d /media/usb/crossepg
root 556 555 1 05:25 ? 00:01:11 /usr/crossepg/crossepg_downloader -r -d /media/usb/crossepg
root 586 565 0 06:52 pts/0 00:00:00 grep crossepg


I have tried to recreate problem manually, but for some reason cannot.
ie:
If I run CrossEPG followed by XMLTV-Importer interactively it always finished and tuner is free afterwards
If I schedule them to run in 15mins and put the stb in standby, it has always worked. Tuner is free after power on

The attached logs are the debug log for a scheduled download from standby, success for 21:25 15Apr, and failure for 05:25 16Apr.
Also included is the crossepg log for the same time period.

Comparing the good run with the failed run, it seems the tuner locks onto 13E okay, but then fails when reading through the titles.
CrossEPG downloader just hangs and the tuner is never released.

Wondering if any of you experts could take a look at the logs and see if there anything unusual about them:confused:


Have been doing a lot of searching on here and other forums (German and PLi) to see if there any issues.
Besides changes to the base image, CrossEPG has been upgraded to 0.81 and uses a different method of tuner selection/usage to read the OpenTV data, and the et4x00 drivers were updated in Nov2014 along with a kernel change from 3.8.7 to 3.14.16.

I can see tuner issues reported with the new drivers, but not sure if it's related.

Suspicions are that it could be related to updated drivers/kernel:confused:

Also was wondering, does anyone know of anyone who might have archives of older images?
Interested to see what would happen if I flashed a version of Apollo with the newer version of CrossEPG but the older kernel/drivers for the et4x00 (possibly around build 065-070)?

WW

[white_westie]

Just an update on this

From looking at debug logs, CrossePg seems to stop when reading epg stream from 13E - it tunes in okay, but stops when downloading titles or summaries, and leaves the tuner locked out from the frontend.
Reversed the order of the download ie: 13E before 28E - same problem
Always works when run interactively or when scheduled to run within the next hour.
Ran a test where I changed schedule to download 13E only every hour - ran perfectly for 6 hours or so.

One thing I have noticed is that when it's in this locked state, a command line reboot or init 6, or a menu restart will actually hang the stb soon after it restarts ie: the box will come back onto the network, I can login and watch the debug log, the tv shows the bootlog screen and even goes to display the info box showing what the current channel should be, but then it locks up - have to power off/on to get it going again.

Since CrossEPG 0.8 is always hanging when this lock occurs, I removed it using the Plugin Browser, and installed (well copied really) the individual files from the older 0.6.2 version from my et9x00 (still running vix3.0 build 666). I deleted the epg.dat, the crossepg database, rebooted the stb and was able to manually download the epg using opentv 28E and 13E.
Not only that, but it has run successfully at 05:25 the last 2 mornings.:confused:

Am looking for an older version of Apollo about 6months old, as that is when xtrend released new drivers with support for the newer 3.14.16 kernel.
Theory is to see if an older Apollo image with older drivers and 3.8.7 kernel, installed with the newer CrossEPG 0.8 have the same problem!

[matt007]

Here are the old versions for your box buddy:


http://www.openvix.co.uk/index.php?dir=ET-4x00/Archives/

[Tkr001]

Those archives don't go back far enough. The old ones have been lost following the "server hacking"

[white_westie]

Update

Went back to CrossEPG 0.8 on my et4x00 and problem with 13E reappeared
Removed/Reinstalled via plugin browser (worked for some in earlier threads) but no change.

Installed Apollo 166 on my et9x00 (uses older kernel 3.8.7), configured CrossEPG OpenTV to download both 28E and 13E and got the same problem! Stopping while downloading 13E. Does not lock up stb as it has 2 tuners but still crossepg download processes left running.

Conclusion at this point is that it's related to downloading from 13E only.

Have stopped using in now on 13E and CrossEPG completing every morning on my et4x00 and et9x00.

MODS: maybe move this thread to the EPG section as I believe it's specific to CrossEPG