Channel list scan question

[pixim]

Can anybody tell me :

1 - why when I do a scan I never receive the same channel list? I flush my channel list this morning and do a rescan to have my channel list up to date, but I realize that some channel are now missing. I do the scan 3-4 time and now these channel are back... Weird...

2- Why some transponder have a great signal and other does not have signal? Is it possible to FIX a Sat on a dedicated transponder or we need all of them? I have a dual NLB, so I can scan SD sat and HD sat... But each I get random channel list, and some channel once selected have a "no signal status"

Thank's for your help!

[Gilles]

Very good question, same thing here... No one know ?

[harddrive4096]

same boat.

[jvvh5897]

Well, you could try the advice in the last post of http://www.satfix.to/showthread.php?198509-scanning

I would guess that the box tuner does not lock in to the signal quick enough for the (blind) scan to see the signal and so extract the channel data from the stream. You could try to slow down the scan with single TP scans or by going into the code and seeing what is going on. Easier might be to take the data from James Uplink site and use it to generate a channel list that you then load into the box rather than rely on scans (you might want to see if you can dump out your channel list and learn to edit it, then see if you can upload it to the box correctly). These thing can be done (I have a non-Jynx box with DSS channel list derived from the 101 degree sat TPN mapping data--I save the xml data as text then use a little python code to parse through the data for the channels on the satellite I like and then save in binary form that I can cut-and-paste into channel list for the box).

A slow lock-in can be an issue with tuners if the frequency is a little different from what the box expects--that can be due to LO in the LNB being a little off from what you tell the code that it is. That forces the tuner chip to search for lock rather than just finding it right away. SR setting can do much the same but tuner usually has easy time with as big SR as the prov uses.

[diode]

If you are using a DPP dual LNB, the Jynxbox does not emit enough power to power the internal switch. Try using two single lnbs with a switch or use a dpp44 switch with a power inserter.

[jvvh5897]

Hum... I knew that the box had LNB drive issues, but trouble running only two LNB--that is limiting. I would think the issue would show up just changing channels too.

For the heck of it (and because the channel list for the box is very similar to openbox and I want to do a little editing for my s9 box true-FTA list), I downloaded the list that you find here: http://www.satfix.to/showthread.php?...10-119-amp-129
It seems there are lots of 0x10000 sized 'chunks' in there. A chunk for each satellite you scan and an "All satellite" chunk (and some other stuff that would be a poor idea to post without a little editing). I've written some rough python code that lets me print out the 0x10000's chunk of "All satellite"--well, some of it. I've got it printing out the Satellite list, the TPs for those satellites, the satellites that have been scanned and am working on getting the channels out of the data too.
There is an Ali channel list editing program that half-way works on letting you view the udf file (you can't save it after edit--it just screws up the thing royally). But with that program I can tell that I am doing things roughly right in my python code.

Here is a little part of what I've gotten so far:
found @ f0c0ff04 00000000
found @ f0c0ff01 00010000
found @ f0c0ff02 00020000
found @ f0c0ff03 00030000
found @ f0c0ff05 00060000--these are the search terms for the 'chunks' and where I found them in the file.

Some of the satellites:
1 Telstar 12
2 NSS 7/C
3 NSS 7/Ku
4 Hispasat 1CD
5 NSS 10
6 NSS 806
7 Intelsat 11
8 Intelsat 14/C
9 Intelsat 805
10 Intelsat21C
11 Intelsat21Ku
12 Amazonas/C
13 Amazonas/Ku
14 EchoStar 12/15
15 Telstar 14

Some of the TP for satellite 44--that is one of the EchoStar sats and one that was scanned

1 44 12224 20000 V
2 44 12239 20000 H
3 44 12253 20000 V
4 44 12268 21500 H
5 44 12268 20000 H
6 44 12282 20000 V
7 44 12297 20000 H
8 44 12311 21500 V
9 44 12326 20000 H
10 44 12341 20000 V
11 44 12355 20000 H
12 44 12370 20000 V

I'm not dealing with all the data for satellites or TP--I just do not know what all the bits are for, but the general idea seems to be there.

[diode]

Hum... I knew that the box had LNB drive issues, but trouble running only two LNB--that is limiting. I would think the issue would show up just changing channels too.

DPP LNBs need more power so that the internal switch between the two Sats operates correctly. Diseqc switches and an array of single lnbs are much more compatible for FTA boxes. If you do a manual scan each TP and wait for a signal on each TP you should be able to scan all the channels but the as jvvh5897 has pointed out you will have problems when you change channels.

[jvvh5897]

Makes one wonder why that was not an issue in the OP.

Well, more progress on reading the udf file. Seems one of the chunks has pointers to the data--that chunk has header string FC C0 FF FF FF and is found at 0x70000 in the file I mentioned earlier. Here is what the start of that chunk looks like:
070000 FC C0 FF FF FF FF FF 01-00 00 00 A5 FF FF FF FF
070010 00 00 00 00 1B 0D 01 08-C0 02 62 66 03 01 3C C0

There are 0xd1b entries, each are 7 bytes long, those are 4 data bytes and 3 addr bytes.
01 08-C0 02 62 66 03--the pointer is to 0x36662 addr, the satellite is 0x2c0 (0x2c0/16=0x2c--. the 44th satellite in the sat list).
The 2nd byte seems to be TP on the sat 0x8/4=2 so the 2nd TP. The first byte might be the number of the channel on that TP--not sure yet.
The data in the 7 bytes fields is ordered roughly as channel data, default TP, default sat. But the channel data is really a mix of data.
Following the 7 byte section is a little channel selected history then a duplicate of the 0xd1b entries--in the file I looked at the second copy might be the 'active' one:
075BD0 CA 0C 01 00 00 00 00 02-1D A8 A0 03 6F 27 06 A5--history info field always ends with 0xa5
075BE0 02 0F 3C 30 03 A7 27 06-A5 0F F0 0F F0 1B 0D 01--0F F0 0F F0 might be a separator
075BF0 08 C0 02 62 66 03 01 3C-C0 02 A5 AB 03 01 24 C0

[jvvh5897]

When you go to the address pointed to in the chunk, you find an entry that repeats the first 4 data bytes of the 7 byte field and there is a length byte immediately following that gets you to the end of that entry. The scans are saved in new chunks and the pointer area updated, but the old data seems to be retained. So, if you search for "TNT" Unicode string you find it over and over depending on how often you have scanned. It may be that if you hit button to take the box to default settings that the old stuff is cleared out--I might try that with my openbox.
That Ali ch list editor I mentioned uses a script.ini file that has the field info for the TP/Sat/Ch data--an easy way to figure out what all the bits mean in a field would be to take a close look at that file.

[jvvh5897]

It is actually pretty interesting that the jynx ch list has two groups of pointers to the scanned data. I used my python code to pull just the ch data that is pointed to into a bin file and both have 1881 channels and 141K bytes of data--guess that is an indication of a good scan with no new channels and no name changes but maybe a few TP reassignments or PID changes.
The python code is only 10K right now--all ascii text. Good enough I think to do edits on that I needed. Might be easy way for you guys to exchange scan info--141K is smaller than 1.2Meg (though compression will end up with about the same size). Last I looked James Long uplink site was down.