Cool, I did not expect to have it work that smooth!!
Because no one on this world tested this kind of device before on an AzBox.
I think for the unknown we can add some timeout, after some time if not all information is received just insert Unknown channels (with the technical stream location within the ATSC transport stream).
It just takes a few days to think about what is best for those things.
Results 271 to 280 of 331
-
03-28-2015,05:45 AM
Last edited by Sundtek; 03-28-2015 at 05:51 AM.
-
03-29-2015,05:45 PM
I am very pleased with this ATSC system in the Duo2. The terrestrial channels produce an excellnt picture.
-
03-29-2015,08:47 PM
I agree.... it's very enjoyable to now have fta and atsc in one receiver again. Now I can put the Sonicview in the closet and make room for a new receiver.
-
03-30-2015,08:18 PM
Checking to see how the Sundtek handles highly amplified signals. Used the Vu+ Zero and its antenna for this test.
Increasing the in-line amplification does not appear to overload the device. I added an additional amplifier that drove the SNR over 150% on some frequencies. Doing this did not seem to bother the device.
-
03-31-2015,04:12 PM
If everything goes well EPG should be available within the next 2 weeks, it looks a little bit crappy to have those fields empty in your Engima2 user interface.
-
03-31-2015,04:23 PM
It would definitely be a welcomed addition. Thanks for your time and effort in all respects to this project.
-
04-08-2015,04:26 PM
It looks like the Sundtek ATSC driver was updated today.
-
04-08-2015,11:41 PM
Not for the ATSC, I will let you know when ATSC relevant changes are ready.
The main feature update is Blindscan support for DVB-C (Digital Cable devices for Europe), there's no other device out there which supports that on all those settopboxes.
The logic is quite interesting, maybe lateron it might also be possible to do something similar with ATSC for automatically scanning all the frequencies.
-
04-10-2015,08:07 PM
My only channel problem now is two muxes or frequencies that are being assigned the same id. I have found this problem in 2 muxes, but have no idea if it exists in any of the others in the ATSC table.
Here is a list of the 4 frequencies that I have separated because of channel issues:
eeee0000:0000:0000
t 562999999:2:5:5:3:2:4:4:2:0:0:0
eeee0000:0000:0000
t 568999999:2:5:5:3:2:4:4:2:0:0:0
/
eeee0000:031f:0000
t 652999998:2:5:5:3:2:4:4:2:0:0:0
/
eeee0000:0325:0000
t 694999999:2:5:5:3:2:4:4:2:0:0:0
/
653 and 695 MHz Will be returned to my main Atlanta scan table because they do not give any problems.
563 and 569 MHz Are being identified in the same way, so one of the two muxes does not work when they both are scanned. These two muxes will remain separated until the problem is fixed.
lamedb files for each mux and then 1 for all 4 muxes is attached.
-