Humax HDR-Fox T2 moved from UK to Australia

Unfortunately I have a job list containing many things of higher urgency/priority, but...

I tried the export database option in the hidden service menu and got files channel.db, rsv.db, and setup.db added to the UPD. The import option is likely to pull in all three, so I am guessing that if the channel.db file is transplanted into another unit's set and then imported, it will transfer the tuning. Here goes...
 
...and rsv.db should transfer the recording schedule...

The only issue is that it conceivable that two devices on the same aerial could end up with different indices for the channels in the database meaning that transplanting the database like this could muck up any existing scheduled recordings. Not a problem for the OP who just wants the tuning done so he can start using the box.
 
Success! As one might expect, the new channel.db required a reboot to establish, but I have (by this process) copied the tuning setup from a HD-FOX to an HDR-FOX. I can (in effect) create a library of tuning files and spawn them across my units (one with the Wales services, one without - by deleting those services in the HDR-FOX and extracting the channel.db file again).

The recording schedule was mangled after the first reboot - edited highlights you might say, presumably corresponding with recordings on services which were not modified by the tuning update. I reckon there was also a risk that the remaining schedule entries might not work properly if there were other factors in the tuning import which the schedule check process (Humax) did not scan for. A WebIF schedule restore and reboot sorted that out, and I took screen shots of the WebIF schedule listing of the "before" situation (very easy on iPad - screen shots are added to the camera roll) to compare with - no sign of the restore problem that other people have reported.

It strikes me that the database export/import process is a way for non-CFers to influence the operation of their boxes to a limited extent. 1800T/2000T?
 
I compared the scan data from both Brisbane and the Sunshine Coast, and also with channels.db from Brisbane. I've read the earlier posts carefully, although there is still a lot I don't understand. I decided to hack the channels.db down to just the single ABC multiplex, which has four TV and two radio channels in TBL_SVC.

I had to change the TBL_TS record ulFrequency field.

I had to change the six TBL_SVC records' usVideoPid, usAudioPid and scanField fields to match the last three values in my channels scan file. (Incidentally, the hSvc values were automatically regenerated).

I also had to trim the TBL_PRV table down to the single record for ABC.

I copied the channels.db file to the humax after executing "/etc/init.d/S90settop stop", then ran the sync and reboot commands (thanks prpr). When the humax restarted it successfully tuned into the six ABC channels!

Although I can manually add back the other four multiplexes, I see that some of the channels have slightly different values for CODE_RATE_HP and GUARD_INTERVAL between Brisbane and the Sunshine Coast. I currently do not know which fields in TBL_SVC need to be changed, and with what integer values. Can anyone help?
 
Black Hole said:
Success! As one might expect, the new channel.db required a reboot to establish, but I have (by this process) copied the tuning setup from a HD-FOX to an HDR-FOX. I can (in effect) create a library of tuning files and spawn them across my units (one with the Wales services, one without - by deleting those services in the HDR-FOX and extracting the channel.db file again).
Click to expand...
This has not worked trying to duplicate the settings to another HD-FOX :(
 
Did you try my method?
It might be useful if the CF could optionally replace the channel.db file at startup in the same way it replaces rsv.db with the contents of rsvp.db, if it exists, for the recording schedule.
 
No, I took the simple approach of trying to import the .db files by hidden menu. Not had time to work out why it didn't take.
 
Well, I dunno. Must have been finger trouble. I went through the procedure again today (copy DB to USB, swap channel.db, copy DB to Flash, reboot) and it worked fine.

I do have CF installed, just no UPD installed and no network connection. I guess Telnet would have worked if I had plugged in a network.
 
Brian Burch said:
I compared the scan data from both Brisbane and the Sunshine Coast, and also with channels.db from Brisbane. I've read the earlier posts carefully, although there is still a lot I don't understand. I decided to hack the channels.db down to just the single ABC multiplex, which has four TV and two radio channels in TBL_SVC.

I had to change the TBL_TS record ulFrequency field.

I had to change the six TBL_SVC records' usVideoPid, usAudioPid and scanField fields to match the last three values in my channels scan file. (Incidentally, the hSvc values were automatically regenerated).

I also had to trim the TBL_PRV table down to the single record for ABC.

I copied the channels.db file to the humax after executing "/etc/init.d/S90settop stop", then ran the sync and reboot commands (thanks prpr). When the humax restarted it successfully tuned into the six ABC channels!

Although I can manually add back the other four multiplexes, I see that some of the channels have slightly different values for CODE_RATE_HP and GUARD_INTERVAL between Brisbane and the Sunshine Coast. I currently do not know which fields in TBL_SVC need to be changed, and with what integer values. Can anyone help?
Click to expand...

Well, after spending some time updating the data for every channel in the five multiplexes, my HDR Fox-T2 successfully tunes into all 31 channels. I made a few typos, but was able to correct the channels.db records and reduce the number of "unavailable or scrambled" stations. Despite my worries about some of the parameters being wrong, the reception appears to be OK on all of them. I have one station left from Brisbane that does not exist locally, so I will try to delete it using the remote (as suggested above for Welsh programs).

The channel numbers shown were different to those listed in the various offline TV guides and my TV set, so I hacked the TBL_SVC usLcn fields to match the values I would presumably have if auto-tune were working... all looks good.

The only significant problem I have left is the Electronic Program Guide(s), which are stubbornly empty. This thread has become quite long and so I will start a new one to deal with the missing EPG data.
 
:frantic:
I will start a new one to deal with the missing EPG data.
Click to expand...
Wouldn't have thought that necessary, as the title of this thread is still relevant. Only 35 posts. On the 'other site' they start a new thread at 500 posts.
 
Black Hole said:
Well, I dunno. Must have been finger trouble. I went through the procedure again today (copy DB to USB, swap channel.db, copy DB to Flash, reboot) and it worked fine.
Click to expand...
I tried the trick on another HDR-FOX, but this time it didn't take. Same "finger trouble"? I did not get the chance to look into it.
 
Trev said:
:frantic:Wouldn't have thought that necessary, as the title of this thread is still relevant. Only 35 posts. On the 'other site' they start a new thread at 500 posts.
Click to expand...
This is summary of my knowledge and the current status of the missing Electronic Program Guide my humax HDR Fox-T2:

In the UK it "just worked". From the hidden menu I presume the choice of BBC as "provider" is relevant. From folklore I have always believed the EPG data for all free-to-air UK channels was transmitted on the BBC multiplex.

In Brisbane (when configured to auto-tune for Germany and with a "provider" of BBC) it sort-of worked. It has the same behaviour as an Aussie-sourced Topfield STB and also my UK-sourced Samsung TV. The behaviour suggests that each multiplex transmits the EPG only for its own channels. One has to tune to a channel within a multiplex of interest, then press the "guide" button and wait for it to populate. As soon as you move the EPG cursor out of the current multiplex (because all other channels are shown as blank), the original multiplex's information disappears and the new multiplex's EPG starts to populate. It is tedious, but better than nothing! Consequently, the "find" feature only works on the currently-populated segment of the EPG. Thankfully, once a program has been scheduled for recording, it retains its EPG data. There does not seem to be any series-link information and the EPG window is 6-to-7 days maximum.

Although my humax channel.db has been successfully hacked to make all five of the Sunshine Coast multiplexes and the 31 channels work, the EPG remins empty.

I have updated the custom firmware epg command line tool to 1.2.0, but "epg raw" and "epg dumpraw" both fail with the message "mmap: Invalid argument".

Using my physical remote control, I assigned favourite channels 1 to 5 as ABC (usLcn 2), SBS ONE (usLcn 3), SC10 Sunshine Coast (usLcn 5), Seven Sunshine Coast (usLcn 6) and WIN Sunshine Coast (usLcn 8). I tried using the web interface settings for EPG Channel Group to 2, 1, then none, but the EPG display is always empty.

I have installed dvbsnoop and started to learn about it. I think the EPG is transmitted as the Event Information Table (with a pid of 18 0x12). I have confirmed this by snooping the ABC and Seven multiplexes. I can capture the EPG data from both multiplexes: as xmltv files with the tv_grab_dvb program; and as a hexdump using dvbsnoop on pid 0x12.

The header information that is unique to each snoop seems to be: Service_ID, Version_number, Transport_stream_ID and Original_network_ID (three of which are flagged as "not yet defined").

I've trawled channels.db looking for similarities with these fields:-
  • Three multiplexes in TBL_TS have matching values in their usOrgNetId fields, and two have values that are different.
  • The records in TBL_TS have the same (right and wrong) values in their usOnId fields. Also, it seems they all have different values in their usTsId fields to those reported by dvbsnoop.
If this makes any kind of sense, do you think these anomalies are related to the empty EPG data? If so, it is appropriate to hack the dvbsnoop values into my channels.db?
 
This stuff is waaay beyond my knowledge, but if it is any help: my understanding of the UK Freeview EPG system is that the entire EPG data is transmitted on all the multiplexes, not just one (and we know this is the case because the whole EPG populates without switching services). Each mux transmits EPG data in a rotation which takes about 15 minutes (this is disputed, but I remember that figure being quoted in the early days) for the full cycle, but high priority data is transmitted more frequently in the cycle than low priority data. High priority data is the listing for the services on the current mux and the current day, down to services on other muxes later in the week.
 
Black Hole said:
This stuff is waaay beyond my knowledge, but if it is any help: my understanding of the UK Freeview EPG system is that the entire EPG data is transmitted on all the multiplexes, not just one (and we know this is the case because the whole EPG populates without switching services). Each mux transmits EPG data in a rotation which takes about 15 minutes (this is disputed, but I remember that figure being quoted in the early days) for the full cycle, but high priority data is transmitted more frequently in the cycle than low priority data. High priority data is the listing for the services on the current mux and the current day, down to services on other muxes later in the week.
Click to expand...
Thanks very much for explaining how it works in the UK. Clearly, my presumption was wrong. Equally clearly, the co-operative scheme you describe has significant advantages (for the ordinary user) over the piecemeal scheme adopted in Australia. There is obviously a trade-off in the time taken to fully populate the guide, and presumably the "owner" of each UK multiplex could (would?) give priority for transmission of data for its own segment of the global EPG...
 
Brian Burch said:
I have installed dvbsnoop and started to learn about it. I think the EPG is transmitted as the Event Information Table (with a pid of 18 0x12).
Click to expand...

You're right - the gory details are in
http://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.14.01_60/en_300468v011401p.pdf

As BlackHole says, all multiplexes in the UK carry all EPG information. Each sends it in four different tables using PID 0x12:

Those tables are:

1) actual TS, present/following event information = table_id = 0x4E;
2) other TS, present/following event information = table_id = 0x4F;
3) actual TS, event schedule information = table_id = 0x50 to 0x5F;
4) other TS, event schedule information = table_id = 0x60 to 0x6F.

The first table is the smallest containing only now/next (present/following) information for channels carried on the current multiplex and then they get bigger as you go down the list. As they get bigger they are transmitted less often, although still often enough.

Edit: xyz321 did some research and clocked the total data for all tables together at between 200-300MiB of data per hour.

If this makes any kind of sense, do you think these anomalies are related to the empty EPG data? If so, it is appropriate to hack the dvbsnoop values into my channels.db?
Click to expand...
Most likely, and yes. When I have access to my Humax again I'll look to see how the EPG data correlates to the entries in that table. Did you select the original network and TS ids from anywhere?
 
You must log in or register to reply here.
Back
Top