| Author |
Message |
< TAP and patch development ~ DescExt firmware patch (like DescriptionExtender) |
|
Page 3 of 8
|
| chunkywizard |
Posted: Fri Sep 28, 2007 9:39 pm |
|
|
|
MyStuff Team
Joined: 13 May 2005
Posts: 9219
Location: Sindlesham, Berkshire Tx: Hannington
|
RT data does not need DE, only EIT data. Not sure how often it hppens but to find out just load the mei file into excel!
CW |
_________________ Toppy:TF5800 F/W: 1365PaTcHeD
TAPs: MyStuff | EPG2MEI | FontManager | SecCache UK | Extend | FastScanGUI | EIT_sub_game | MyInfo | ScreenCapture with OSD | MHEG On/Off
MyStuff Manual & Logos | Known Bugs | Recommended F/W |
|
| Back to top |
|
| simonc |
Posted: Fri Sep 28, 2007 9:50 pm |
|
|
|
Frequent contributor
Joined: 12 Apr 2005
Posts: 5616
Location: Cheltenham
|
| Yes, DE is only needed for the EPG broadcast over the air. If you only use eit2mei for gathering the radio EPG, you can get by without DE - the descriptions tend to be pretty brief. |
|
|
| Back to top |
|
| glenmcfar |
Posted: Fri Sep 28, 2007 9:56 pm |
|
|
|
Frequent contributor
Joined: 07 Dec 2006
Posts: 4519
Location: Dundonald, Ayrshire, Scotland
|
Well, the patch is in now, DE is gone and I'm gonna wait until I don't have any timers due then start with a fresh eit2mei scan.
Its not really mission critical, so there's no rush.
R2 - why don't you patch MyStuff into the firmware next (or other EPG replacement TAPS ) ?
Glen. |
_________________ H/W: TF5800 | URC-7555 | Asus | Best Firmware Ever!
A/S: SecCacheUK, EitSub, EPG2MEI, Display, Extend, QuickJump, FontManager, TapLauncher, MyStuff
T/L: TapCommander, Surfer, MeiSearch, MediaManager | HDFW, CutAds, Sudoku |
|
| Back to top |
|
| simonc |
Posted: Sun Oct 28, 2007 3:16 pm |
|
|
|
Frequent contributor
Joined: 12 Apr 2005
Posts: 5616
Location: Cheltenham
|
@R2-D2
Can you provide any information about the 5.14.02's EPG table? So far I've guessed at the following:Code:
byte char00; //00 // top 2 bits - valid; lower 5 bits - running status
// byte char00a:2; //00
/. byte char00b:1; //00
// byte running_status:5; //00
byte char01; //01
byte duration_hour; //02
byte duration_min; //03
word short04; //04 //??? normally 0000
word event_id; //06
word start_date; //08 //mjd
byte start_hour; //0a
byte start_min; //0b
word end_date; //0c //mjd
byte end_hour; //0e
byte end_min; //0f
byte event_name_length; //10
byte parental_rating; //11
word original_network_id; //12
word transport_stream_id; //14
word service_id; //16
word short18; //18 //??? normally 0000
word sat_index; //1a
word short1c; //1c //??? normally 0000
word short1e; //1e //??? normally 0000
word short20; //20 //??? normally 0000
word short22; //22 //??? whats this? - a 'random' number, different for each entry
word short24; //24 //??? normally 0000
word short26; //26 //??? whats this? - a 'random' number, different for each entry
byte *event_name; //28 //ptr to event name, event description is offset by event_name_length bytes
byte *extended_event_name; //2c
byte char30; //30 //01 if extended present else 00
byte num_extended; //31 //number of extended items
word extended_length; //32 //extended length
word short34; //34 //0001 if extended present else 0000
word short36; //36 //0001 if extended present else 0000
word short38; //38 //mjd - date added ? - utc time?
word short3a; //3a //??? normally 0000
word short3c; //3c //??? normally 0000
word short3e; //3e //??? normally 0000
word short40;
word short42;
byte genre; //44 // genre
byte subgenre; //45 // subgenre
word short46; //46 //???
word short48;
word short4a;
word crid_length; //4c
word short4e;
byte* crid;
Looks like only one CRID is available. Don't know which. Again, they've stored it in dynamic memory, despite crids appearing to always be empty or a fixed length. |
|
|
| Back to top |
|
| bdb |
Posted: Sun Oct 28, 2007 3:42 pm |
|
|
|
Frequent contributor
Joined: 18 Oct 2005
Posts: 499
|
I have:
Code: typedef struct{
byte char00; //00 //for 1288: top 2 bits = valid, next 3 bits = running status, next 3 = ???
// byte char00a:2; //00
// byte running_status:3; //00
// byte char00b:3; //00
byte char01; //01
byte duration_hour; //02
byte duration_min; //03
word short04; //04 //??? normally 0000
word event_id; //06
word start_date; //08 //mjd, utc time
byte start_hour; //0a
byte start_min; //0b
word end_date; //0c //mjd, utc time
byte end_hour; //0e
byte end_min; //0f
byte event_name_length; //10
byte parental_rating; //11
word original_network_id; //12
word transport_stream_id; //14
word service_id; //16
word short18; //18 //??? normally 0000
word sat_index; //1a
word short1c; //1c //??? normally 0000
word short1e; //1e //??? normally 0000 or 6500
word short20; //20 //??? normally 0000
word previous; //22 //previous, a link to the previous epg entry, by date/time, ffff terminates
word short24; //24 //??? normally 0000
word next; //26 //next, a link to the previous epg entry, by date/time, ffff terminates
byte *event_name; //28 //ptr to event name, event description is offset by event_name_length bytes
//for >=1288, event fields reordered
union {
struct{
byte char2c; //2c //01 if extended present else 00
byte num_extended; //2d //number of extended items
word extended_length; //2e //extended length
byte *extended_event_name; //30
}fw;
struct{
byte *extended_event_name; //2c
byte char30; //30 //01 if extended present else 00
byte num_extended; //31 //number of extended items
word extended_length; //32 //extended length
}fw13;
}event;
word short34; //34 //0001 if extended present else 0000
word short36; //36 //0001 if extended present else 0000
word date_added; //38 //mjd, utc time - date added ?
word short3a; //3a //??? normally 0000
word short3c; //3c //??? normally 0000
word short3e; //3e //??? normally 0000
//for >=1288, eventtable is 0x44 long, genre
//for >=1400, genre moves
union {
struct{
byte content_nibble1; //40
byte content_nibble2; //41
word short42; //42 //user_nibble1,2? - not filled in by fw?
}fw13;
struct{
word short40; //40 //0000
word short42; //42 //0000
}fw14;
}genre;
//for >=1400, eventtable is 0x64 long, crid
byte content_nibble1; //44
byte content_nibble2; //45
byte crid32_strlen; //46 //crid32 strlen (series)
byte byte47; //47
byte *crid32_str; //48 //crid32 ptr string
byte crid31_strlen; //4c //crid31 strlen (repeat)
byte byte4d; //4d
byte byte4e; //4e
byte byte4f; //4f
byte *crid31_str; //50 //crid31 ptr string
byte crid33_strlen; //54 //crid33 strlen (recomendation?)
byte byte55; //55
byte byte56; //56
byte byte57; //57
byte *crid33_str; //58 //crid33 ptr string
dword dword5c; //5c //00000000
dword dword60; //60 //00000000
}type_eventtable;
crids are NOT a fixed length
They store 3 types:
31 - repeats
32 - series
33 - recomendations? - I've not seen any of these broadcast.
-the data_added field is wrong; it now seems to be at offset 3c; not sure whether it has just moved, or if the original structure was wrong.
also see update of crid tap
bdb |
|
|
| Back to top |
|
| simonc |
Posted: Sun Oct 28, 2007 4:34 pm |
|
|
|
Frequent contributor
Joined: 12 Apr 2005
Posts: 5616
Location: Cheltenham
|
| Thanks bdb. On my quick search last night I didn't see anything other than the series link crids and they were all 7 characters long. Are they entirely dynamic or is there an upper limit to their length? |
|
|
| Back to top |
|
| bdb |
Posted: Sun Oct 28, 2007 4:58 pm |
|
|
|
Frequent contributor
Joined: 18 Oct 2005
Posts: 499
|
They do mainly seem to be 7 characters but I have seen some of other lengths, and some in the format '/42155/001'. It looks like topfield allocate 0x18 bytes for each one, but since I don't have a spec. [what's so secret?], I dont know if there is an upper limit.
bdb |
|
|
| Back to top |
|
| R2-D2 |
Posted: Mon Oct 29, 2007 10:26 am |
|
|
|
Frequent contributor
Joined: 18 Dec 2006
Posts: 12149
|
bdb wrote: It looks like topfield allocate 0x18 bytes for each one Aren't they copied into eventStrings, so take up 32 bytes at least?
Here's what my event struct looks like:Code: EitEvent (5.14.02) @ 80343f98
16000 entries of size 100
0 0 byte flags
status:2
runningStatus:3
1 1 byte pad?
2 2 word duration (hr:min)
4 4 dword eventID
8 8 dword startDateTime
12 c dword endDateTime
16 10 byte eventNameLen
17 11 byte parentalRating
18 12 word netID
20 14 word tsID
22 16 word serviceID
24 18 word
26 1a word satIndex
28 1c word
30 1e byte descLang (1st byte ISO639 lang = "short desc rec?")
31 1f byte pad?
32 20 dword prevEventIndex
36 24 dword nextEventIndex
40 28 char* eventName (not terminated, description follows terminated or up to char 250?)
44 2c char* extDesc
48 30 byte extPresent
49 31 byte numExt
50 32 word eventNameTotalLen
52 34 word extDescLen
54 36 byte sharedText (str alloced elsewhere)
55 37 byte extNumDescrs
56 38 byte extLastDescrNum
57 39 byte extLangMatch
58 3a word dateAdded
60 3c word pad?
64 40 dword EVTUNK1 (-1)
68 44 byte genre
69 45 byte genreSub
70 46 byte crid32Len
72 48 char* crid32
76 4c byte crid31Len
80 50 char* crid31
84 54 byte crid33Len
88 58 char* crid33 |
|
|
| Back to top |
|
| R2-D2 |
Posted: Sun Nov 04, 2007 11:15 pm |
|
|
|
Frequent contributor
Joined: 18 Dec 2006
Posts: 12149
|
FireBird's new PatchID mechanism means that it's now as easy as this to detect the DescExt patch:Code: PatchIsInstalled(0x80000000,"De"); Obviously you need to link against FireBirdLib, or just borrow the code from the fwpatches section. |
|
|
| Back to top |
|
| DX |
Posted: Mon Nov 05, 2007 11:40 am |
|
|
|
Frequent contributor
Joined: 06 Apr 2005
Posts: 2622
|
I've added the above patch detection to test versions of eit2mei, mei2archive, and SeriesLink.
The setting AutoDetectDEP will still override this, but by default auto detection of the De patch should now work (provided the new patcher was used). Any problems let me know, otherwise I'll release these versions in a few days. |
|
|
| Back to top |
|
| glenmcfar |
Posted: Mon Nov 05, 2007 12:45 pm |
|
|
|
Frequent contributor
Joined: 07 Dec 2006
Posts: 4519
Location: Dundonald, Ayrshire, Scotland
|
So you mean I can remove my AutoDetectDEP line and it should autodetect DescExt ok?
Glen. |
_________________ H/W: TF5800 | URC-7555 | Asus | Best Firmware Ever!
A/S: SecCacheUK, EitSub, EPG2MEI, Display, Extend, QuickJump, FontManager, TapLauncher, MyStuff
T/L: TapCommander, Surfer, MeiSearch, MediaManager | HDFW, CutAds, Sudoku |
|
| Back to top |
|
| DX |
Posted: Mon Nov 05, 2007 1:42 pm |
|
|
|
Frequent contributor
Joined: 06 Apr 2005
Posts: 2622
|
That's the theory.
I've downloaded the new versions of the hdfw tap and PatchPackV2.zip. The De patch was successfully auto detected when applied to firmware 5.13.65. I assume other firmwares will also be OK but I haven't tried any. |
|
|
| Back to top |
|
| R2-D2 |
Posted: Mon Nov 05, 2007 4:16 pm |
|
|
|
Frequent contributor
Joined: 18 Dec 2006
Posts: 12149
|
| I think that if the patch ID detection proves stable, then it should obsolete the old method as (for a couple of reasons) we'd like everyone to move over to the new patch tools. I'm also hoping that (thanks to DX's hard work on these core TAPs) this patch will now be ready for more mainstream usage (and a place in the sticky patch thread). |
|
|
| Back to top |
|
| andyrogers |
Posted: Mon Nov 05, 2007 9:52 pm |
|
|
|
Frequent contributor
Joined: 07 Dec 2005
Posts: 814
|
Hi R2-D2
With the 5.14.02 firmware containing serieslink data available to the firmware now, could your DescExt patch be made to make the serieslink data visible to other taps now without the requirement of using the crid tap at the moment.
Like how you have managed to get Genre to be available in the patch.
Thanks
Andy |
_________________
Firmware: 5.14.09 Patched
AutoStart Taps: MyStuff v5.52b, eit2mei beta 7.8m7, , Power Manager v1.2, Tap Commander v1.32, TF5000 Display v1.53a, Discription Extender v2.3, SDS 1.3b, QuickJump 1.72
Other Taps: Sudoka, mei2archive, mei2eit, snake, meisearch
|
|
| Back to top |
|
| R2-D2 |
Posted: Mon Nov 05, 2007 10:01 pm |
|
|
|
Frequent contributor
Joined: 18 Dec 2006
Posts: 12149
|
andyrogers wrote: With the 5.14.02 firmware containing serieslink data available to the firmware now, could your DescExt patch be made to make the serieslink data visible to other taps now without the requirement of using the crid tap at the moment. It's far too early to be considering things like this, I think. There are a lot of changes in 5.14.02, and some changes that happened in recent 5.13.X firmwares that have been reverted in 5.14.02, making me think they are not really related (as the different SysID might also suggest).
And also there's no room for extra fields. The CRID data can be quite long, so an alternative approach would be needed. Maybe a new API?  |
|
|
| Back to top |
|
|
|
|