Click here to go to the forum index Click here for the home page
 
Author Message

<  MyStuff  ~  Proposed update to MEI Format

Page 3 of 4
Goto page Previous  1, 2, 3, 4  Next
Bawbagg
Posted: Mon Jan 16, 2006 12:01 am Reply with quote
MyStuff Team Joined: 11 Aug 2005 Posts: 1122
wooders wrote:
I believe that it would be better to include a version number now, even if it is never needed in the future. In the event that later on there becomes a need to modify TIE format again then we will already have a version number in place so that the consumer taps can tell the difference between the old and the new format. I'm just trying to look ahead and cover the possibility of future changes.
Fair enough. Let's have $version too.

wooders wrote:
Another field that springs to mind is:
$source - where the data was grabbed from, e.g. the base url of the RT, Bleb, Digiguide website
ahhh - that's a really good idea.

wooders wrote:
BB, you haven't explicitly said anything about radio data in your last post, I think that it would be helpful if you would mention whether or not you see this being included in TIE.
Yes - I think it should. The only reason it's not there at the moment is because it's not provided by Radiotimes.com. The new V3 of the XMLTV Radio Times software can grab EPG data from more than one source and build it into a single file. I'm really not very interested in radio though, which is probably why I didn't bother to mention it. Embarassed

Does everyone agree that radio data be in the same file??

BB

_________________
TAPs: MyStuff Something or other + whatever CW recommends
MEI readme and latest version at http://my.opera.com/bawbagg
Current MyStuff Known Bugs http://www.BobDsMyStuff.co.uk/Bugs.shtml
View user's profile Send private message Visit poster's website
LordCake
Posted: Mon Jan 16, 2006 10:40 am Reply with quote
Frequent contributor Joined: 03 Jul 2005 Posts: 217 Location: Manchester
Bawbagg wrote:
...Does everyone agree that radio data be in the same file??...

I would like to see this. I've just been writing a perl script to get radio data from bleb.org into the existing MEI format. The broadcast EPG data for radio is not very good and only seems to cover a couple of days ahead.

_________________
Model: TF5800PVR F/ware: 5.13.65EfNfCyXpXwSXlUUuHPTCeGmSrUxEsRs Xmitter: Winter Hill Q: ~100% S: 76-95% Aerial: Group C/D bandpass filter Taps: MyStuff v4.54d, RemoteExtender v1.5, deselect v1.0Connected: Toppy<->undeclocked debianSLUG + iguanaIR running: ftpd-topfield, rt2mei, bleb2tie & lirc
EPG data for radio channels: http://my.opera.com/bleb2tie/
View user's profile Send private message
rwg
Posted: Mon Jan 16, 2006 10:52 am Reply with quote
TAP author Joined: 29 Oct 2005 Posts: 604 Location: Oxfordshire
LordCake wrote:
nwhitfield wrote:
...Adding extra fields just because you might need space later seems silly; keep what you have in the same order. ...


Why is it silly? and why do you think it would change the order of fields?



it's easier to just define the format to say that there *may* be extra fields at the end and that readers should be prepared for this. It's easy to code (in fact the easiest to write reading code would probably deal with this automatically).

The spec will just say something like 'future versions will not change the order or meaning of existing fields, but may add extra fields at the end of each line. Reading software should be prepared to such ignore extra fields that it is not capable of understanding'.

Robin

_________________
Toppy: TF5800PVR; Firmware: 5.13.65 + patches + aXel; Remote: Pronto RU940; Autostart TAPs: MyStuff 6.5 and friends
View user's profile Send private message Visit poster's website
rwg
Posted: Mon Jan 16, 2006 10:55 am Reply with quote
TAP author Joined: 29 Oct 2005 Posts: 604 Location: Oxfordshire
Bawbagg wrote:
I'm blown over by the interest this has generated Very Happy.

...

This is intended to be a stake in the ground. Have I missed anything??


Looks good to me, along with the version and source tags ideas. Lets also commit to keeping the LCN data where it is and adding service ID as a new field if there is need for it.

Robin

_________________
Toppy: TF5800PVR; Firmware: 5.13.65 + patches + aXel; Remote: Pronto RU940; Autostart TAPs: MyStuff 6.5 and friends
View user's profile Send private message Visit poster's website
LordCake
Posted: Mon Jan 16, 2006 11:14 am Reply with quote
Frequent contributor Joined: 03 Jul 2005 Posts: 217 Location: Manchester
rwg wrote:
LordCake wrote:
nwhitfield wrote:
...Adding extra fields just because you might need space later seems silly; keep what you have in the same order. ...


Why is it silly? and why do you think it would change the order of fields?



it's easier to just define the format to say that there *may* be extra fields at the end and that readers should be prepared for this. It's easy to code (in fact the easiest to write reading code would probably deal with this automatically).

The spec will just say something like 'future versions will not change the order or meaning of existing fields, but may add extra fields at the end of each line. Reading software should be prepared to such ignore extra fields that it is not capable of understanding'.

Robin

Now that sounds ok to me. My concern was that future changes to the file spec should not cause existing applications to stop working. The bald assertion that having "spare" extra fields was "silly" made no sense to me.

_________________
Model: TF5800PVR F/ware: 5.13.65EfNfCyXpXwSXlUUuHPTCeGmSrUxEsRs Xmitter: Winter Hill Q: ~100% S: 76-95% Aerial: Group C/D bandpass filter Taps: MyStuff v4.54d, RemoteExtender v1.5, deselect v1.0Connected: Toppy<->undeclocked debianSLUG + iguanaIR running: ftpd-topfield, rt2mei, bleb2tie & lirc
EPG data for radio channels: http://my.opera.com/bleb2tie/
View user's profile Send private message
DX
Posted: Mon Jan 16, 2006 12:29 pm Reply with quote
Frequent contributor Joined: 06 Apr 2005 Posts: 2694
Bawbaggs' summary and Wooders additions sound good to me. They'll provide extra information without needing many (if any) changes to existing TAP's. As for Radio Channels I'd say keep them in the same list.
View user's profile Send private message
Toppy-boj
Posted: Mon Jan 16, 2006 7:56 pm Reply with quote
Frequent contributor Joined: 05 Jan 2006 Posts: 252
I think when we state what dat is required, The Tivo should show the way. you need information so that sug TAP as JaGsEPG can use to help automate recordings.

Tivo uses the "first transmission date" to see ifs a "first run" ( ie not a repeat0. To cover repaets on the same day, it will not record something which has same title and description if recorded in the last 28 days. It allows to auto record things based on actors . directors

Therefore kind of data needed is a repeat flag, where you could set JAGs EPG not to record it ( using the Not tag of ~, ie ~ (R)). for simplicity this repeat flag may "R "in brackets which could be added to title name.

just some thoughts

_________________
TF5800, IA On, TS On, F/W: MS6 Recommended F/W 2/6/2009 -Xl+B4C0CwEvEzFmFsIOtPeRtTdVr
TAPs: EPG2MEI v0.94; TF5000 Display v1.53; Font Manager 1.0d; MyStuff 6.0; Extend v1.7; SecCache (UK) v0.4; TSSaver v0.5; TAP Commander 1.34; MyInfo B4.0; Power Manager v2.1;
Sig generated by MyInfo on 23/9/09
View user's profile Send private message
DX
Posted: Sun Jan 29, 2006 9:58 pm Reply with quote
Frequent contributor Joined: 06 Apr 2005 Posts: 2694
Having just been trying to code support for BST/DST I think it would be useful to be able to get at GMT times. While local time is usually the most convenient there are occasions where being able to work out the GMT time would be an advantage.

One possibility, which I hope wouldn't be too difficult to update existing TAps to support, would be to keep local times but add a GMT offset where it's known.

The existing format for midday on Jan 1st is

200601011200

If the MEI generator knows about GMT and you are in the UK this would become

200601011200+0

and midday on July 1st would be

200607011200+60

If a TAP doesn't care about GMT it just parses the first 12 digits in the same way as it would now and ignores the rest.

Alternatives I've thought of would be to add new fields to contain the GMT offset, or perhaps have global settings indicating the GMT offsets for various date ranges.
View user's profile Send private message
wooders
Posted: Sun Jan 29, 2006 11:49 pm Reply with quote
Frequent contributor Joined: 25 Aug 2005 Posts: 428 Location: The National Forest
Would there be any advantage in timestamps always being in GMT?

Would this help overcome timer problems across GMT/BST changes?

_________________
TF5800, TS On, F/W: MS6 Recommended F/W 12/9/2009 -Sy+Pe
TAPs: EPG2MEI v0.96; Extend v1.7; Font Manager 1.0d; MyInfo B5.5; MyStuff 6.4; WSSkiller V2.12d; SecCache (UK) v0.4; EIT Sub (Game) v0.6; MHEG On/Off A3;
Sig generated by MyInfo on 30/3/12


Let rt2mei 1.1a feed your Toppy with EPG data from the Radio Times website.
Download rt2mei from http://www.wooders.co.uk/rt2mei
View user's profile Send private message Visit poster's website
DX
Posted: Mon Jan 30, 2006 1:38 am Reply with quote
Frequent contributor Joined: 06 Apr 2005 Posts: 2694
I was thinking of backward compatibility when I suggested Local+Offset Time. Having GMT+Offset would also work, but would mean more changes to existing taps/generators.

The whole area of GMT vs Local Time on the Toppy seems a bit of a nightmare around the clock change. I'm not sure I've got everything straight in my mind yet but here's my current understanding of what's going on.

Internally I believe the Toppy keeps information in GMT format, but the TAP api's work with Local Time. So if a TAP sets a timer before the clock change the Toppy applies the time offset applicable at the moment of setting, not the moment the timer executes. So timers set to execute on the other side of a clock change will go off an hour late/early.

The problem is users like to see Local time, even if it's the other side of a clock change. In order to handle this TAPs need to know what the time offset is both at the point of setting a timer, and when the timer executes. That way they can adjust the timer before setting it to compensate for the upcoming change in time offset.

When displaying any timers the TAP needs to reverse the process and adjust them the other way so the user sees what they expect.

Even if TAPs get it right you still have the problem the Toppy EPG and Timers display don't do this. In the run-up to clock change the Toppy EPG shows times on the other side out by an hour, as does the Toppy timer display. Except that doesn't apply to repeat timers of course.

I can't help feeling the whole thing would be easier if BST/DST was abolished and we had the same time offset all year round. Laughing
View user's profile Send private message
DB1
Posted: Mon Jan 30, 2006 9:19 am Reply with quote
Frequent contributor Joined: 30 Mar 2005 Posts: 728 Location: Orpington
DX wrote:
I can't help feeling the whole thing would be easier if BST/DST was abolished and we had the same time offset all year round. Laughing


Agreed - I work with a commercial package that still has problems twice a year and it is past it's tenth birthday Sad

Anyone know if the Toppy implements DST like Win PC's or like *nix?

( DOS based OSes have the hardware clock in local and an offset to get GMT. *nix boxes always keep GMT and the offset gives local. I think that is the correct way to do things. Does make cross platform fun.)

_________________
TF5800, F/W: 5.13.65AbBfBqC0CbCeCkCwCyDEcEeEfErEsEvEzFFsGmHHeIKtNfOtPPcPePsRRaRhRpRsSSdSrStT2TdTfTpUUuXXpXwXl TAPs: TF5000 Display v1.53; QuickJump 1.72; Power Manager v2.2; MyInfo B5.6; DescriptionExtender 2.23; Remote Extender 1.6; Archivev1.0a; mei2archive BETA 3.8l7; EPGnavigator v5.1c; UK Auto Scheduler v0.73.1; Extend v1.7; Power Restore V0.7.8
Tx: CP
Sig generated by MyInfo on 14/4/13
View user's profile Send private message
DX
Posted: Mon Jan 30, 2006 9:56 am Reply with quote
Frequent contributor Joined: 06 Apr 2005 Posts: 2694
DB1 wrote:

Anyone know if the Toppy implements DST like Win PC's or like *nix?

( DOS based OSes have the hardware clock in local and an offset to get GMT. *nix boxes always keep GMT and the offset gives local. I think that is the correct way to do things. Does make cross platform fun.)


I think the Toppy is perhaps closest to DOS from an api point of view. Internally it's GMT (sync'd to the broadcast), but externally (TAP api and UI) it's local (without a TAP api to find the offset - makes life fun).
View user's profile Send private message
LordCake
Posted: Mon Feb 13, 2006 6:57 pm Reply with quote
Frequent contributor Joined: 03 Jul 2005 Posts: 217 Location: Manchester
The BBC now have TV-Anytime format EPG data available for download (see:
http://www.toppy.org.uk/forum/viewtopic.php?t=3911 )

Will the new TIE format be able to cope with all the potential TV-Anytime data Question

_________________
Model: TF5800PVR F/ware: 5.13.65EfNfCyXpXwSXlUUuHPTCeGmSrUxEsRs Xmitter: Winter Hill Q: ~100% S: 76-95% Aerial: Group C/D bandpass filter Taps: MyStuff v4.54d, RemoteExtender v1.5, deselect v1.0Connected: Toppy<->undeclocked debianSLUG + iguanaIR running: ftpd-topfield, rt2mei, bleb2tie & lirc
EPG data for radio channels: http://my.opera.com/bleb2tie/
View user's profile Send private message
nwhitfield
Posted: Mon Feb 13, 2006 7:25 pm Reply with quote
Site Admin Joined: 20 Mar 2005 Posts: 9577
They've had that there for a while, and it offers some interesting possibilities, like true series link, if you could process the data. And even just using the TVAT data for the BBC channels would be interesting - you could dynamically reschedule recordings to avoid clashes, for example, if you knew that a particular BBC show was repeated later.

What you'd need to do, really, is have a system that would generate EPG data from mixed sources, so that some channels could be sourced from the TVAT data, and others from places like RadioTimes.

To fit in with the TVAT data, you'd probably need a couple of extra id fields, essentially one for the crid, which is the programme's own reference, and another for the series.

In fact, TVAT doesn't actually have a 'series' link as such, but rather the concept of a collection, which is usually a series, but could be something else, like a season of programmes, I suppose. And a programme can be a member of more than one collection. So you'd either need a potentially open ended field to store that, or you could make a decision that the format would allow only one or two collection references; perhaps a primary and a secondary one, with the convention that the primary collection would always be used for a series.

Nigel.

_________________
Support this site - make a donation to our running costs
View user's profile Send private message Visit poster's website
LordCake
Posted: Mon Feb 13, 2006 8:02 pm Reply with quote
Frequent contributor Joined: 03 Jul 2005 Posts: 217 Location: Manchester
nwhitfield wrote:
What you'd need to do, really, is have a system that would generate EPG data from mixed sources, so that some channels could be sourced from the TVAT data, and others from places like RadioTimes.

My interest in this topic is because I am writing a php application to get radio station EPG data from bleb.org into in MEI format (ready for the day MyStuff will handle radio). The application runs after rt2mei and simply appends to the files genearated by rt2mei. Perhaps a similar approach could be used if someone were to write a "tva2mei" or "tva2tie" php script?

nwhitfield wrote:
To fit in with the TVAT data, you'd probably need a couple of extra id fields, essentially one for the crid, which is the programme's own reference, and another for the series.
@Bawbagg: any plans to include these fields in TIE Question

_________________
Model: TF5800PVR F/ware: 5.13.65EfNfCyXpXwSXlUUuHPTCeGmSrUxEsRs Xmitter: Winter Hill Q: ~100% S: 76-95% Aerial: Group C/D bandpass filter Taps: MyStuff v4.54d, RemoteExtender v1.5, deselect v1.0Connected: Toppy<->undeclocked debianSLUG + iguanaIR running: ftpd-topfield, rt2mei, bleb2tie & lirc
EPG data for radio channels: http://my.opera.com/bleb2tie/
View user's profile Send private message

Display posts from previous:  

All times are GMT + 1 Hour
Page 3 of 4
Goto page Previous  1, 2, 3, 4  Next

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum