HD stops working after zapping, plus movie player question

[sympa]

Thanks for making this Neutrino version available. I just installed in on HD instead of the AAF I had there. I write this in English, but feel free to answer in German as I am a subscriber to c't magazin

My installation process was to delete AAF from my boot partition and extract Neutrino (4877 STM24) there. I did not change the bootargs or the old mini uboot I was using. And I use the (64MB) swap partition I had on the drive - just edited /etc/fstab to enable it.

It seems to work fine and it is a big big improvement over E2.

I run into a bug which I cannot find on the forum. Maybe related to wrong bootargs or something else?

HD works fine, SD works fine. But after some zapping, when I change from an SD channel back to HD, the screen stays black. Sound is decoded, but no video. Also, the resolution in the infobar is not updated. When switching back to SD I have a picture again. I need to reboot to see HD again - a soft restart is not enough.

It is not clear what triggers this situation - it can occur with zapping, but it is not easy to trigger quicly. Maybe time related.

Also a (newbie) question: I try to play TS files written by Enigma2, but I get a crash with error 139 in the VFD. Could this be related to extra streams in the TS or to something else?


Thanks in advance,

Thomas from Amsterdam

[BPanther]

You should try the newer v2 of Neutrino (called NMP). And important: Don't use FAT32 for the Swap partition, FAT32 is too instable, better ext2 or ext3. If the name of the partion SWAP or swap the partition will be mountet automatically, you must not changing the fstab. Same for HDD if the partiton name RECORD.

[sympa]

I'm now trying [BP-NMP-BETA]_ufs910_BASE-rev6014_HAL-rev569-exp-next_NMP-rev6307-exp-next.tar.gz, which is playing my old recordings well.

I must still get a feel for it; searching channels seems unstable. I even reinstalled it as it plain out refused to receive anything any more after a lot of channel searching. After a bit of channel switching it would even refuse to show any OSD, with only the green LED blinking on a remote key press.

After the reinstall it is fine again. Now scanning again, but it gets stuck on 1W - 11862000 H, 28000 7/8 DVB S1. According to Lyngsat that was an empty transponder, so maybe it is now switched off. Having NIT search off now as that pollutes the transponder table with false info, which it can get stuck on.

If there is anything useful I can do (logs perhaps, though preferably not from the serial port as I have to dig up hardware ) I'll be glad to help.

UPDATE: after wainting a long time (30 minutes maybe) the channel search went on, and skipped the malfunctioning transponder! It seems to try longer for higher-SR transpondersand shorter on low-SR transponders. Usually this is the other way around als low SR transponders need fine-tuning.

[BPanther]

Wow, 30min is a long time for skipping a wrong tp. You can make logs serial or if box running via telnet and the command

setconsole

All serial outputs now redirected to the telnet console. With

setconsole -r

you can disable this output. Needed for a clean exit from telnet.

What do you mean with "fine tuning"? Are the frequencys not correct for your box?

[sympa]

Some measurements. Tried on 1W 10.99 GHz H (non existing) some symbol rates and noted how long it would take for the scan to fail. The tests were run in the order shown below:

SR (msps) - seconds
1.5 msps - 7s
3 msps - 10s
6 msps - >600 s (canceled)
3 msps - 9 s
2.5 msps - 17 s
3 msps - 6.7 s
2 msps - 6s
2.5 msps - 9 s
1 msps - 15 s
3.5 msps - 13 s
4 msps - 6 s
4.5 msps - 11 s
5 msps - 6 s
5.5 msps - 60 - 120 s
5.5 msps - ~ 150 s
5.25 msps - > 300 sec (canceling)
5 msps - 9 s
5.001 msps - 5 minutes and still scanning.

So under 5 msps it seems to go pretty fast, and it seems to misbehave above 5MSPS.

This is without UseUnknown and without HighSR selected on the UFS910, rev6014-569.

[BPanther]

Thanks. Maybe a driver problem, but i'll test it again (astra 19.2E with invalid tp data) on other receivers to verify if driver or neutrino problem...

[sympa]

Another experience:

I was watching BBC One HD this morning. Then I switched to BBC Olympics, to see if they started transmission yet. It is in the channel list, but has no transmission yet I think.

When I did that, Neutrino died. Died as in: no OSD when I press buttons, just the green LED. OK-mute-mute-mute did not seem to restart Neutrino (maybe I should wait longer) so I used OK-pow-pow-pow. That restarted the box.

After the restart I do get OSD again, but no signal and no reception. And if I change satellite, there is not even the rotor indication. For good measure I also switched the box off and on again, but still the same.

And after zapping a bit (without getting a signal), it goes back into the "no OSD only green LED" state.

I've had this experience before and I fixed it with cleaning out the partition and reinstalling the tarball. But I suppose I can see what is changed/corrupted between the tarball and my verion, right? Any hints?

When it is hung memory does not seem to be the problem:

Code: Alles auswählen

ufs910:~# cat /proc/meminfo 
MemTotal:          47900 kB
MemFree:           16392 kB
Buffers:             688 kB
Cached:            13500 kB
SwapCached:            0 kB
Active:             9764 kB
Inactive:          12168 kB
Active(anon):       7744 kB
Inactive(anon):        8 kB
Active(file):       2020 kB
Inactive(file):    12160 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:         64252 kB
SwapFree:          64252 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          7772 kB
Mapped:             5136 kB
Shmem:                 8 kB
Slab:               3284 kB
SReclaimable:       1272 kB
SUnreclaim:         2012 kB
KernelStack:         520 kB
PageTables:          296 kB
Quicklists:          168 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:       88200 kB
Committed_AS:     181104 kB
VmallocTotal:     507824 kB
VmallocUsed:        4520 kB
VmallocChunk:     499644 kB

ufs910:~# cat /proc/swaps 
Filename                                Type            Size    Used    Priority
/dev/sda2                               partition       64252   0       -1

If it is hanging, killall -9 neutrino shows the green system failure screen and error 137 in the display. After restart I have the OSD back, but still no signal. Zapping a few times shows no rotor indication and the OSD becomes non functional again.

To get things working I can reinstall, but I'd rather help find the cause.

[sympa]

I made a diff over the tarball and the non-working file system.

First attempt was to change neutrino.conf with the tar version. This did not help.

Then I replaced bouquets.conf and frontend.conf. Restarting neutrino did not help, but after rebooting the box I have signal again on 19.2E. After correcting some settings I can scan 28.2E again. So it might be these files, or it could be other files I touched while I restored some settings. Before restoring files I did try touching 'obvious' settings with usals etc, but I may have missed Service -> Setup Tuner -> Setup Tuner -> Use usals for all. But that setting would have been there before crash.

In case it is useful the full diff (~100K) is available on https://cloud.ziggo.nl/publications/doc ... ebefd7d1eb

[sympa]

Usually a 27.5msps TP is finished in a few minutes if there is no signal. Now I was scanning Arabsat, which is rather weak. At a certain one it got stuck, scanning for over 2 hours. I canceled it in the end. While it was still finishing it showed the following lines on the console, about 2 lines per second. Finally I unplugged the LNB cable, but the FE_HAS_SIGNAL / FE_HAS_CARRIER messages continued.

Code: Alles auswählen

[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_CARRIER
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_CARRIER
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_CARRIER
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_CARRIER
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_CARRIER
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_CARRIER
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_CARRIER
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_CARRIER
[fe0] FE_HAS_SIGNAL
[fe0] ############################## poll timeout, time: 8682421 msec (min 2000 max 8682421)
[scan] scanning took: 9240 sec
[scan] found 44 transponders (8 failed) and 0 channels
/var/tuxbox/config/scan.stop failed: No such file or directory

What I meant with fine tuning is that (in my theory at least) tuning a TP with an SR of 2 MSPS needs to be accurate to less than a MHz. LNBs are not perfectly accurate, so I think the receiver may have to try some different frequencies. Also these signals are often weaker and there are fewer of them to catch on to. That is why I think most receivers take longer to tune to a low SR TP than a high SR TP: if there is no signal they keep trying longer on a low SR, usually.

Code: Alles auswählen

[scan] waiting 9 seconds for motor to turn satellite dish.
[fe0] tone on
[fe0] FE_SET_TONE took: 56 msec (min 40 max 60)
[fe0] tune to 11843000 DVB QPSK 3/4 H/L srate 27500000 (tuner 1243000 offset 10600000 timeout 4000)
[frontend.cpp:getEvent:490] ioctl: Value too large for defined data type
[fe0] FE_HAS_SIGNAL
[fe0] FE_HAS_CARRIER
...

The ioctl error message, is that OK?

When canceling, if teh cancel doesn't work/takes a huge time, I can unplug the LNB cable and the canceling works. The carrier/signal messages do not seem to change much; neither does the signal indicator.

[BPanther-Mobil]

You can change the offset frequency, maybe it helps.

[sympa]

That is not the problem when scanning...it just takes too long for the higher SR's, and sometimes takes very long. The low SR TPs do not have this problem.

For the rest the NMP seems to be a lot better than Neutrino v1!


Thanks, Thomas

[BPanther]

I hope we can find the scan problem, but maybe take a while...

[sympa]

If I can help let me know...

Would it be useful to see if the HS_SIGNAL and HAS_CARRIER messages (and there are a lot of them even with LNB unplugged) appear:

- on higher and lower SR's equally
- appear more or fewer, depending on UseUnknown

Or do all boxes behave the same in this regard anyway?

Thomas

[sympa]

Switched back to the useUnknown parameter. It seems the scanning is a bit faster, but still takes very long sometimes if there is no or poor signal. There is no influence on the HAS_SIGNAL/CARRIER messages.

BUT the good thing is that with useUnknown, I find channels on Arabsat (Badr 4/5) with a small (70 cm) dish. I couldn't find any channels yesterday without using useUnknown. But it is still very on some transponders (27500ksps) but not as slow as yesterday. It will now finish the scan of 44 transponders in less than 2 hours, I think.

I see that messages are defined in the tuner driver for FE_HAS_SIGNAL, FE_HAS_CARRIER, but also for FE_HAS_VITERBI and (they are issued together) FE_HAS_SYNC and FE_HAS_LOCK. Maybe something is interpreting FE_HAS_SIGNAL or FE_HAS_CARRIER as a reason to keep trying that transponder. I wonder what would happen if the tuner driver would be changed from:

Code: Alles auswählen

if (lock & 0x01)
  *status |= FE_HAS_SIGNAL;
if (lock & 0x02)
  *status |= FE_HAS_CARRIER;
if (lock & 0x04)
  *status |= FE_HAS_VITERBI;
if (lock & 0x08)
  *status |= FE_HAS_SYNC | FE_HAS_LOCK;

to

Code: Alles auswählen

if (lock & 0x08) {
  *status |= FE_HAS_SIGNAL;
  *status |= FE_HAS_CARRIER;
  *status |= FE_HAS_VITERBI;
  *status |= FE_HAS_SYNC | FE_HAS_LOCK;
}

It just *might* prevent Neutrino from sticking to the transponder so long (if this solves it, the fix probably belongs in Neutrino, to wait a bit for LOCK instead of any message).

Or do I misunderstand the communication between driver and Neutrino or is the driver hanging itself up? This is my first attempt at looking at the source so bear with me. as I notice something "hangs" when there is no signal, so maybe it is not willing to tune in that state.

[BPanther]

Hmm, is it not the same as deleting the 0x01..0x04 because now always only "*status |= FE_HAS_SYNC | FE_HAS_LOCK" is set if "lock & 0x08"? All above will be overridden by the last?!