203 replies to this topic

[pieterg]

I haven't changed any of that code, so the behaviour if the file is missing still should be the same as before.

...it was question for all, if we talking here about info for recorded files

Untill now, the stored eit section was inserted into the OSD, as if it came from pid 0x12.
So there was no support to use the text fields from the meta file.
Now that we no longer will be using EIT, indeed we could do a fallback to the titel/description from the meta file.

[awx]

I haven't changed any of that code, so the behaviour if the file is missing still should be the same as before.

...it was question for all, if we talking here about info for recorded files

Untill now, the stored eit section was inserted into the OSD, as if it came from pid 0x12.
So there was no support to use the text fields from the meta file.
Now that we no longer will be using EIT, indeed we could do a fallback to the titel/description from the meta file.

if the same information is already available in the meta file then there is no need to store an info file or am I mistaken?

[pieterg]

I haven't changed any of that code, so the behaviour if the file is missing still should be the same as before.

...it was question for all, if we talking here about info for recorded files

Untill now, the stored eit section was inserted into the OSD, as if it came from pid 0x12.
So there was no support to use the text fields from the meta file.
Now that we no longer will be using EIT, indeed we could do a fallback to the titel/description from the meta file.

if the same information is already available in the meta file then there is no need to store an info file or am I mistaken?

The description in the meta data is limited to a single line (probably with some limited length)

[awx]

I haven't changed any of that code, so the behaviour if the file is missing still should be the same as before.

...it was question for all, if we talking here about info for recorded files

Untill now, the stored eit section was inserted into the OSD, as if it came from pid 0x12.
So there was no support to use the text fields from the meta file.
Now that we no longer will be using EIT, indeed we could do a fallback to the titel/description from the meta file.

if the same information is already available in the meta file then there is no need to store an info file or am I mistaken?

The description in the meta data is limited to a single line (probably with some limited length)

ah ok, then we definitely need the info/eit file

[bigroma]

Crossepg still don't work.

[ims]

It seems, m_event_name, m_short_description and m_extended_description are in writeMeit empty.
Btw, there in readMeit must be solved when is meit empty or corrupted.

Edited by ims, 26 January 2012 - 20:22.

[awx]

It seems, m_event_name, m_short_description and m_extended_description are in writeMeit empty.
Btw, there in readMeit must be solved when is meit empty or corrupted.

thanks, I already have a fix for the one issue I just don't know why they are empty

[awx]

Here is a set of patches again, this should fix the issues with the new eit format. Also the extension name as has been changed to .info

Attached Files

•  patch.eit.info.tar.gz   8.52KB   6 downloads

[ims]

thanks. It seems, it works now.

next step: must be added for .info same operations as there are for .eit file, when is movie deleted, moved, copied ...

[awx]

wh

thanks. It seems, it works now.

next step: must be added for .info same operations as there are for .eit file, when is movie deleted, moved, copied ...

Thanks for the update,
could you tell me if you are using a plugin for these operations, or the video screen.
I will make a patch for the video screen later

if you want to test it out already you can edit the file in MovieSelection.py
In the function createMoveList, just before eitName = srcBase + '.eit'
you can add the following

infoName = srcBase + '.info'
if os.path.exists(infoName):
moveList.append((infoName, os.path.join(dest, baseName+'.info')))

[awx]

Any comments on if the info file should be a binary format or a text format?
Text format is potentially easier to add additional fields in the future and be backwards compatible but theres no reason why we cant be backwards compatible with a binary format.
Text info makes it a little more painful for handling multi line text.

[ims]

could you tell me if you are using a plugin for these operations, or the video screen.
I will make a patch for the video screen later

For copy, move it works now. "Delete" does not remove "info".
MovieCut plugin - create second movie with .cut - s not created for this "info" too.

[awx]

could you tell me if you are using a plugin for these operations, or the video screen.
I will make a patch for the video screen later

For copy, move it works now. "Delete" does not remove "info".
MovieCut plugin - create second movie with .cut - s not created for this "info" too.

There are likely two places that the .info needs to be added in mcut.cc to get that to work.
I will check what is happening with delete, as I cant see from the source right now why it doesnt delete all files

[ims]

Here is patch for MovieCut bin file.

Attached Files

•  0001-added-operations-with-.info-too.patch.tar.gz   907bytes   4 downloads

[pieterg]

Any comments on if the info file should be a binary format or a text format?

I'd say text format.
What do you store in the file?
If it's just title+description, it might suffice to define the first line to be the title, and the remainder to be the description.
If we need genre as well, perhaps a second line.
If there's more fields that we need, it will get more complicated.

[awx]

Here is a patch for copy/delete/move on the movie selection screen
Patch is like I have previously described.
Tested copying, moving and deleting and the info file is updated accordingly.

Attached Files

•  movieselectionfix.tar.gz   671bytes   7 downloads

[awx]

Any comments on if the info file should be a binary format or a text format?

I'd say text format.
What do you store in the file?
If it's just title+description, it might suffice to define the first line to be the title, and the remainder to be the description.
If we need genre as well, perhaps a second line.
If there's more fields that we need, it will get more complicated.

Right now I am storing event id, time, duration, short description, extended description, but I also though it might be useful to store genre at some point ( especially since I have a patch to make genre store ). Also the extended description has more information that we don't use but may want to use at some point.

I thought if it is a text file that it would be something like this
#TITLE
title goes here in case it has new line characters
#SHORT_DESC
safsafsaf
safsasafsf
#EXT_DESC
goes here
1
2

but this format is not really space efficient and is much slower to read

do we need to store event id, start time, duration? is this even used after the event is recored?

Edited by awx, 27 January 2012 - 17:09.

[pieterg]

do we need to store event id, start time, duration? is this even used after the event is recored?

I think only title+description are used at the moment

[ims]

Here is a patch for copy/delete/move on the movie selection screen
Patch is like I have previously described.
Tested copying, moving and deleting and the info file is updated accordingly.

Strange ... same I added . I will see, where was problem, when i will be at home...

[awx]

Here is a patch for copy/delete/move on the movie selection screen
Patch is like I have previously described.
Tested copying, moving and deleting and the info file is updated accordingly.

Strange ... same I added . I will see, where was problem, when i will be at home...

Thanks, let me know, maybe there is still a bug that I am not seeing with my data. (Ofcourse I hope there isnt)