203 replies to this topic

[ims]

hmm... it works for recordings placed on internal hdd ( or on medium connected with Trash), because delete is move to Trash. On next devices is not file "info" removed.

[ims]

for removing .info file on devices without trash must be added there in servicedvb.cpp under line:
res.push_back(tmp + ".eit");
line
res.push_back(tmp + ".info");

Edited by ims, 29 January 2012 - 17:49.

[awx]

for removing .info file on devices without trash must be added there in servicedvb.cpp under line:
res.push_back(tmp + ".eit");
line
res.push_back(tmp + ".info");

Thanks, I will add that to my patches

[awx]

Looking into storing the info file as a string, I think its better to store the data as a binary format in a modified dvb format.
Format something like this
2 Byte size for the entire descriptor.
Loop size
1 byte id
2 byte size
n bytes of data

The only data to store at first would be title and descriptions, possibly with language code for backwards compatibility if we ever decide to store more than one title and description.

Ironicly this is similar to the format that we are try to decouple ourselves from.

[pieterg]

agreed, when we have to use a binary format, a TLV (aka descriptor) format is preferable.

[awx]

agreed, when we have to use a binary format, a TLV (aka descriptor) format is preferable.

Well we don't have to use a binary format, I just thought it removes a lot of the trouble you run into dealing with multi line parsing, worrying about new additional new characters and such.

Before I start doing this please let me know which is the preferred way for the PLi image, for met it doesn't really matter, its just the binary format, is smaller and easier to deal with. Ofcourse harder to edit if you wanted to hand craft .info files for whatever reason.

[pieterg]

What if we just store the description in the info file?
The title is in the meta file already.

I have no objection against using a binary format, but the whole point to get rid of the eit file was to make things easier

[awx]

What if we just store the description in the info file?
The title is in the meta file already.

I have no objection against using a binary format, but the whole point to get rid of the eit file was to make things easier

Storing only the description would work, but then you need to add in data checks to make sure which description you are storing and you also run into the problem that some providers use combined short and extended descriptions.
I have a sample of the new read and write method, and this is much cleaner than the previous version, assuming what I have works.
I don't think I will be able to test it today, so Ill post a patch tomorrow when I have at least done some initial testing ( still might be possible today, but not likely )

[ims]

would be big problem saving old .eit file too for compatibility with others images or it is impossible yet ?

[pieterg]

If the epgcache is no longer going to give us eit data, it'd be a bit weird to (re-)generate an eit section, to store in an eit file

[awx]

would be big problem saving old .eit file too for compatibility with others images or it is impossible yet ?

It might be possible to make some solution, but we would run into the problem that we need to do UTF8 trimming like what is currently being done for data that is coming in. Most likely the only thing that would work 100% properly in other images would be the extended description because this is a combination of extended descriptions, which does have a limit but I don't think any enigma2 image actually enforces that limit so we could abuse that fact.

[awx]

If the epgcache is no longer going to give us eit data, it'd be a bit weird to (re-)generate an eit section, to store in an eit file

I agree, and I don't really like the idea of having to rebuild it, but if it really is a blocking issue for people then I wouldn't be opposed to it, at least not completly.

[awx]

Here are the latest patches for this

Attached Files

•  patches.tar.gz   8.71KB   7 downloads

[ims]

Will be format of .info final yet ? Enigma crashing, when is there in movies recordings with older .info. Or may be reading .info file more safe ? F.eg. when file will be corrupted etc...

[awx]

Will be format of .info final yet ? Enigma crashing, when is there in movies recordings with older .info. Or may be reading .info file more safe ? F.eg. when file will be corrupted etc...

The old .info file is no longer valid with this version, these right now are trial versions to make sure we catch as many bugs as possible. The new format will allow for a slightly more modifiable format, basically giving us 255 - 3 different ids we can use for different data formating, so that if we need to change a field we can create a new id for the modified versiona and use that for future versions, while remaining backwards compatible. All os this has not been finialized and another patch may be made that breaks the current info file format I have submitted ( I wont submit a patch that changes the format now, unless theres a bug or this really needs to be changed )

[awx]

The latest patch seems stable and fine to me.

There is a separate issue for starting a recording right away, that looks like the title data is used from eit information which at some point doesn't have its text properly converted, but I expect this was always there.

[pieterg]

ok, so you think it's ready to be merged?

[awx]

ok, so you think it's ready to be merged?

I think so, I haven't experienced any bad behaviour from the last patches, but just to make sure we have the same thing Ill post them again
Support for the old EIT format looks to work properly, support for the new format looks to be working as well, and most importantly titles are not lost or trimmed but stored in full.

Attached Files

•  patches.tar.gz   8.71KB   4 downloads

[pieterg]

Any objections?

btw, one small remark,
void eServiceEvent::writeInfo(std::string filename)
would be better to either use a const reference, or just pass a const char pointer, to avoid making a copy of the string object.

[awx]

Any objections?

btw, one small remark,
void eServiceEvent::writeInfo(std::string filename)
would be better to either use a const reference, or just pass a const char pointer, to avoid making a copy of the string object.

Good point, that should definitely be changed before commiting the change