bookmark.db

In order to find a workaround for the "start recording force change of channel issue",
we are investigating the interesting file: bookmark.db

In fact we are interested in the resume facility and where this information is stored.
We found it is stored in this file: bookmark.db

Lets start with its situation:
The file is located in: /usr/local/etc/dvdplayer/bookmark.db

But we have find out that the equipment makes a working copy of this file in:
/tmp/ramfs/bookmark.db

So modifications should be done in this place: /tmp/ramfs/bookmark.db


Type of file
This file bookmark.db is a sqlite3 database file.
It can be opened with linux command line sqlite3. Eg.: sqlite3 bookmark.db
Also with sqliteManager plugin in firefox.
(More info: http://code.google.com/p/sqlite-manager/ )


Database schema
This database has many system tables (9):
sqlite> .tables
DB_VERSION_CONTROL SetupKeyValue SetupVCRPlusChMap
SetupAvailableLang SetupTVChannelInfo SetupWlan0Profile
SetupAvailableRegion SetupTVRatingType tParameter


Below in this thread is full schema and sample of contents.

We are interested now in table: tParameter
CREATE TABLE tParameter (id INTEGER PRIMARY KEY, fKey TEXT, fValue BLOB);

This table have three columns:
id , fKey and fValue


tParameter table investigation
It seems is in this table where the resume information is held.
Each time we finish or stop a media file in LG, three consecutive rows are created in the db.
These 3 rows are explained below:

Structure for resume playing in tParameter is quite easy (Where xx are paired number):

xx is the number of playing files, lg has interrupted; it can also be seen as the number of bookmarks elements,
it seems it can store up to 256 elements.

1. row: id, xxm , BLOB (I think that data in this BLOB store a kind of timestamp) (More info below)
( BLOB in the 1st row definitely stores the date & time of last playing (ie the moment of the playing interruption). It is in format of Unix Epoch Time (ie the 32 bit number representing the number of seconds elapsed from January 1, 1970). The nice online converter for Unix Time is here: http://www.epochconverter.com/. So the "m" char in fkey value (xxm) means "modify time", actually. )

As an example we have:
fKey fValue
0m 3DEA134D => reverse bytes: 0x4D13EA3D => in DEC: 1293150781 => convert from Unix Epoch: 24 Dec 2010 00:33:01


2. row: id, xxk , BLOB (URI/filename in hexa). k for "key".
3. row: id, URI/filename in text, BLOB (Full analysis in section; Blob Analysis of the third record below)







Example (for file no. 10)

id	fKey	fValue
31	10m	BLOB	<- 1st row
32	10k	BLOB	<- 2nd row
33	URI filename	BLOB	<- 3rd row

and so on ...

"m" in the 1st row means maybe "modify time"
"k" in the 2nd row means ???


Blob Analysis of the third record
It seems the time of resume is stored here in the first bytes.

Some samples, we have stopped at different times to check which values changed:
1min:30sec = 90sec -> 0x5A Content: 5A0000000A9100000BC5765301000000
2min:00sec = 120sec -> 0x78 Content: 78000000BBBD00000BC5765301000000
4min:41sec = 281sec -> 0x119 Content: 1901000016A201000BC5765301000000
1H:1min:11sec= 61x60=3671sec ->0xE57 Content: 570E000098B10F000BC5765301000000

So, the time in seconds, is converted into hexadecimal, and then stored in reverse way.

BLOB in the 3rd row: first 4 bytes stored resume playing and because it is also 32 bit number I am almost sure that it is also the Unix Time format (but I cannot verified it because I haven't any recording/movie file which will be a couple of days long Very Happy). For .ts recordings there are some additional bytes there which could represent specific information of transport stream format (audio/video synchronization, audio track selection, subtitles displaying etc.). So it is important to copy the COMPLETE 3rd row's BLOB in database from the original file db record (not only the first 4 bytes storing resume playing time) to ensure the identical conditions for correct file resume playing! (see https://ms450.forosactivos.net/t567p40-bookmarkdb#5281 for details)


Thanks user George2005 for helping me in the analysis. More tips, ideas, editions are welcomed to complete this info.

vic1972 escribió:Dial xxx in your system and enjoy, this will download PM3.5 in your system with this new capability to be tested.
First alpha release.

The idea, is that red button repeats the last played movie.

OK, thanks for information, I will test it.

Testeado boton rojo con los siguientes resultados:

_ Casi siempre entra en HOME y vuelve a TDT
_ Otras veces entra en HOME y se queda ahí.
_ Alguna vez entra en HOME, se desplaza por las opciones y entra en una (una vez en picassa, otra en configuracion activando alguna opción..)

He probado a realizar operaciones varias ANTES DE PULSAR EL BOTON ROJO (reproducir un video o hacer distintos cambios de cofiguración) sin que cambie el resultado.

Vic escribió:
The idea, is that red button repeats the last played movie.

La idea es buenísima, si permite volver al evento en reproducción cuando entra una grabación programada y nos manda a TDT.

Entiendo que te refieres ESTANDO EN MODO TDT, porque creo recordar que la función original del boton era ejecutar una serie de variables de repetición EN FUNCION REPRODUCCION. Ahora ha perdido esa función.

Corrígeme si me equivoco. Un saludo

si, solo se utilizas si esta en modo TDT, en modo reproduccion no se toca nada,
deberias poder utilizarlo normalmente,
si no es asi, vuelve a reproducir el tema, y me mandas el log.
saludos

Lo que esta claro, que aun le queda mucho que arreglar, pero este tema es bastante complejo, y no creo que pueda
abarcar todos los caso posibles, solamente lo mas sencillo,
entrar menu, ir a media, seleccionar peli.

vic1972 escribió:Dial XXX in your system and enjoy, this will download PM3.5 in your system with this new capability to be tested.
First alpha release.

The idea, is that red button repeats the last played movie.

So I have just tested Red button - sometimes the red button works well but in other cases it selects different recording or goes to bad menu. But as you have said it is a complex problem because it is not easy to "grab" button sequence and "replay" it again. It is a bad luck that is not possible to run DVDPlayer directly with the filename as a parameter

So I will try to test it more, eg. compare actual button sequences with the Pipemanagement log to try to find a quite reliable approach ...

George2005 escribió: It is a bad luck that is not possible to run DVDPlayer directly with the filename as a parameter

That would be the very best solution indeed.

OK, I would try also to debug a bit the situation
Thanks for the testing, and ideas ..

At First: I wish you Merry Christmas!


I have done some additional tests of RedButton - I have noticed two main problems:
1. Keypress sequence replaying doesn't seem quite reliable
2. The process is quite slow (by design, of course - eg. if I want to go to the 50th recording the down key must be replayed fifty times - even if I use the Page down key!)


I was thinking about the completely different approach:

As I have noticed in the PM log the fullname of current played file is available. What about to create a symbolic link automatically each time of start the playing?

So this symbolic link could always point to the current/most recent played file. The symbolic link could be located in the directory eg. /tmp/hdd/volumes/HDD1/!Recent - the exclamation mark as the first character could assure that the directory would always be at the first position in alphabetical order. So the Red Button task would be quite easy and always the same: go to Media -> HDD -> go to the first directory (ie !Recent) and play the first file (ie symbolic link - it's name could also start with an exclamation mark due the alphabetical order).

I have wanted to check the approach mentioned above manually but I have encountered the problem with symbolic link creation as the HDD filesystem is ufsd - the "ln" command doesn't work on it (it returns "Not permitted") - maybe it could be possible to use something like "fsutil" from NTFS for Linux (Paragon).

The other questions are:
1. Could the DVDPlayer accept the symbolic linked media file?
2. Could it be possible to resume playing (ie "Resume Playing Window") in case of using symbolic link instead of the actual file? Where is the resume playing information (ie last playing time) stored actually?

Hi,
sorry for late resonse, i am away.
We had both the same idea....
in fact, i was going to connect to forum to paste my idea,

is to create force simbolic link (ln -f ) inside REC folder,
so each time the link is create with same filename,


them we execute the $ which directs to rec folder, first file, YES
exactly, we have there our file


so, the trick is very simple,
send the dollar command, and the OK command twice, and we are done!!!

vic1972 escribió:Hi,
sorry for late resonse, i am away.
We had both the same idea....
in fact, i was going to connect to forum to paste my idea,

is to create force simbolic link (ln -f ) inside REC folder,
so each time the link is create with same filename,


them we execute the $ which directs to rec folder, first file, YES
exactly, we have there our file


so, the trick is very simple,
send the dollar command, and the OK command twice, and we are done!!!

Hi Vic,

It sounds great, that we have had the same idea in the same time It maybe a "spirit of Christmas", actually ...

As I have written I have had problems with symbolic links creation. I have got MS450H and the internal HDD uses UFS file system so when I try to create hardlink (ln, or ln -f) the link is zero byte long and in case of softlink (ln -s) I get the warning "Operation not permitted". Another issue is possibility to resume playing (ie "Resume Playing Window") in case of using symbolic link instead of the actual file. So could you test it please?

yes ,
actually I even did some preliminary testing the day before going to xmas holidays,
it is very experimental, but workinfg very good
only with .ts as i hava to finish the programming,
if you want you can give a try
dial XXX
I return tomorrow so i will be able to continue with this

vic1972 escribió:
yes ,
actually I even did some preliminary testing the day before going to xmas holidays,
it is very experimental, but workinfg very good
only with .ts as i hava to finish the programming,
if you want you can give a try
dial XXX
I return tomorrow so i will be able to continue with this

Thanks a lot for your new working version. It works well! I have only encountered some problems with creating symbolic links to filenames which use parantheses, spaces and maybe some non-english characters (unfortunately our TV stations use such characters in EPG) - see picture below. But I think that the appropriate escaping ("") could help. Another problem is with resume playing. As the RecentFile.ts is treated by LG as the different file from its symbolic link target, the playing is not resumed at the actual last position but always at the start of file



But your another idea, ie touching the last played file is excellent !!! It could solve the resume playing problem intrinsically and it is not needed to create any symlinks at all. I am not sure if it is possible to send a command to sort recordings by the "Latest" rule but if so, then RedButton (or the PM directly just after the rec mode detecting) could send "$" command & "Latest" rule sorting command & OK twice and IT'S DONE !!!

Are you both sure you can make links (soft or hard) on NTFS partitions mounted as UFS and accessed by Linux? I'm sorry I didn't try this, but I'm little skeptical.

Keltek escribió:Are you both sure you can make links (soft or hard) on NTFS partitions mounted as UFS and accessed by Linux? I'm sorry I didn't try this, but I'm little skeptical.

As I have tested on UFS it could be possible to create hardlink (which the DVDPlayer is able to play) but not softlink - see picture:



But as I have written yet (see above) touching the last played file it could be better method (IMHO)

Hello,
yes, good point about the type of formats, we will have to check ....

At the very worst situation, we can think about making a copy of the whole file instead of creating a link.
This copy process can be done within a thread would the user is playing the file, in the first seconds ...

More things, yes, only the touch would we fine, but only for files within REC folders,
I have many folders with movies, seriels, etc outside REC folder,
so I think we need to find a complete solution to the problem.

Shall we go to the copy option ....?

vic1972 escribió:Hello,
yes, good point about the type of formats, we will have to check ....

At the very worst situation, we can think about making a copy of the whole file instead of creating a link.
This copy process can be done within a thread would the user is playing the file, in the first seconds ...

More things, yes, only the touch would we fine, but only for files within REC folders,
I have many folders with movies, seriels, etc outside REC folder,
so I think we need to find a complete solution to the problem.

Shall we go to the copy option ....?

Well, we can copy a file instead of creating a link. But I am concerned with the resume playing actually. It could be annoying to manually look for the last played point in the file/recording. I wonder where the resume playing time is located. If it would be possible to retrieve it from somewhere then maybe we can use the command for "Goto" button to perform resume playing ...

no no
I think that is solved.
When ever you replay any file, lg automatically ask to continue in the exact point where it was stopped,
PM, will send automatically a press of the OK button.

So, I think we are fine with that.
Is that what you meant?

vic1972 escribió:no no
I think that is solved.
When ever you replay any file, lg automatically ask to continue in the exact point where it was stopped,
PM, will send automatically a press of the OK button.

So, I think we are fine with that.
Is that what you meant?

Yes, It is exactly what I mean. But I did some tests couple of days ago:
I played a recording (eg. with "rec1.ts" filename), I stopped it at some time (eg. 00:10:00) and then I copied the file "rec1.ts" to "rec2.ts". I tried to play "rec2.ts" - LG asked me to resume playing - Although I confirm to resume it, the playing started from 00:00:00. I did the same with the original file "rec1.ts" and playing resumed correctly at 00:10:00. I got the same result with using hardlink instead of file copying. It seems to me that LG stores the resume playing times somewhere (maybe in any sqllite db file?) according to the appropriate filenames.

hhhhhhhmmmm I see now.
I will have to check that later on....

vic1972 escribió:hhhhhhhmmmm I see now.
I will have to check that later on....

OK, I will also try to find out how LG manages the resume playing information ...

So I have done some investigation and I have realized that the resume playing times are stored in /usr/local/etc/dvdplayer/bookmark.db, table: "tParameter", column: "fValue". In record with appropriate fullname there is a BLOB whose the first 4 bytes store resume playing time in seconds - see picture:

Very good
that bookmark it is a sqlite DB.
So, it will be as simple as:
1. Fetch the offset of original file
2. Add a new row in that DB with the path of the link (or copy) and the offset value.

We need to know if that table, it is like a "LIFO" , that is, like a queue of fixed length (32?),
so all records are overwrited with new ones ....
We need first to do a manual test, to check if the tricks works well.
Today, I am away.
If you have the time, please, do a link or copy of a .ts file,
and try to do the steps specifies above.
Then play this copy or link, to see if it start playing in that offset, that would be the solution
Thanks

vic1972 escribió:
Very good
that bookmark it is a sqlite DB.
So, it will be as simple as:
1. Fetch the offset of original file
2. Add a new row in that DB with the path of the link (or copy) and the offset value.

We need to know if that table, it is like a "LIFO" , that is, like a queue of fixed length (32?),
so all records are overwrited with new ones ....
We need first to do a manual test, to check if the tricks works well.
Today, I am away.
If you have the time, please, do a link or copy of a .ts file,
and try to do the steps specifies above.
Then play this copy or link, to see if it start playing in that offset, that would be the solution
Thanks

OK, I will test it ...

Hmmmmmm, very good hacking

I have tested to change db records for resume playing, but with bad luck Although the first 4 bytes in fValue indicate the actual resume playing time perfectly in all cases, the changing of that value doesn't have any effect so the LG resumes playing at the original time. So I will try to "investigate" the meaning of other BLOB bytes.

Sorry, It has seemed so easy before ...

Heyyyy not to be sorry,
as keltek said this is happy hacking
as most difficulties more fun jajaja

I will try to have a look later at my db,
I put here, in case, i have some minutes outside of the house:
http://dl.dropbox.com/u/684543/varios/ms450h/varios/bookmark.db