PipeMangemente integrated in sourceforge SVN

evr escribió:

George2005 escribió:let me explain the situation - LG machine itself works with db files (eg bookmark.db) by libsqlite library which is included in "monolithic" DvdPlayer, ie using its "native client". The only thing we need to do with sqlite is to add triggers into bookmark.db - but of course we cannot use native client in DvdPlayer so either we can insert triggers into existing bookmark.db (by executing of sqlite3 or direct call using libsqlite3 library) or simply replace existing (original) bookmark.db by our modified version (which already includes the triggers), so in this case it is not needed to use sqlite at all. As we need to decide whether the bookmark.db is original or modified one I added the unique ID (GUID) into db table so it is easy to check the bookmark.db version. So the question is which method of bookmark.db modification (ie trigger inserting by sqlite client/library code or whole file replacing) would be more suitable ...

Thanks for the detailed explanation! However I do not still fully understand it. As far as I can see, bookmark.db contains timestamps indicating the instant each movie has been stopped by the user. So it should regularly be "modified" because users do use the player regularly ¿am I right? On the other hand, to add the unique ID (GUID) and to check if it exists you need to do some sqlite operations, which would anyway need to use sqlite3 or libsqlite3...

So it looks like I am still confused...

Best,

Well, you are right, timestamp of replayed file is updated each time the user stops the playing. It is done by triggers, which are SQL queries inside the database (for simplicity we can say that triggers are something like "internal database functions", however actual db functions are quite different thing). Trigger is run (ie triggered ) by defined action eg updating data record INSIDE the database so it is completely maintained by a "native client", ie libsqlite library integrated in DvdPlayer.
About GUID: as we wanted to avoid using sqlite3 for bookmark.db checking, Victor's PM should check the GUID presence in db file by simple binary searching (like grepping). So in this case (in conjuction with replacing the whole bookmark.db file), we couldn't use any sqlite client at all.

George2005 escribió:Well, you are right, timestamp of replayed file is updated each time the user stops the playing. It is done by triggers, which are SQL queries inside the database (for simplicity we can say that triggers are something like "internal database functions", however actual db functions are quite different thing). Trigger is run (ie triggered ;) ) by defined action eg updating data record INSIDE the database so it is completely maintained by a "native client", ie libsqlite library integrated in DvdPlayer.

Thanks! This makes it clear enough for me definitiveely.

About GUID: as we wanted to avoid using sqlite3 for bookmark.db checking, Victor's PM should check the GUID presence in db file by simple binary searching (like grepping). So in this case (in conjuction with replacing the whole bookmark.db file), we couldn't use any sqlite client at all

I think I am still confused here: if you replace the whole bookmark.dbfile with one "default" one (with the GUID), all the user timestamps will be lost, am I wrong?

Best,

evr escribió:

George2005 escribió:Well, you are right, timestamp of replayed file is updated each time the user stops the playing. It is done by triggers, which are SQL queries inside the database (for simplicity we can say that triggers are something like "internal database functions", however actual db functions are quite different thing). Trigger is run (ie triggered ) by defined action eg updating data record INSIDE the database so it is completely maintained by a "native client", ie libsqlite library integrated in DvdPlayer.

Thanks! This makes it clear enough for me definitiveely.

About GUID: as we wanted to avoid using sqlite3 for bookmark.db checking, Victor's PM should check the GUID presence in db file by simple binary searching (like grepping). So in this case (in conjuction with replacing the whole bookmark.db file), we couldn't use any sqlite client at all

I think I am still confused here: if you replace the whole bookmark.dbfile with one "default" one (with the GUID), all the user timestamps will be lost, am I wrong?

Best,

Of course you are right, exactly, all the user timestamps will be lost by bookmark.db replacing - it is a disadvantage of that approach. However adding triggers into existing db file is possible only by using sqlite client/library call.

George2005 escribió:Of course you are right, exactly, all the user timestamps will be lost by bookmark.db replacing - it is a disadvantage of that approach. However adding triggers into existing db file is possible only by using sqlite client/library call.

O.K. Everything clear for me now. Thanks!

Given the side-effects, I think the replacement approach will not be generally acceptable. So I guess we should forget about this idea and think in changing the current PM code (which invoques the sqlite3 binary) with direct calls to the libsqlite3 library...

Best,

vic1972 escribió:more possible workaorund? I think it is very good we discuss the different approaches :)

O.K. Now that I seem to have understood what is all this "red button" and "bookmarks.db" buzz about ;) I think there might be a relatively simple solution without touching bookmark.db at all.

If I have understood it well, the purpose of "red button" is to enable a single IR command to go back and play the file which was last being played before stopped by the user or by the DvdPlayer. Since DvdPlayer keeps the timestamp of the point where file was stoped, the only problem is to know which was last played file when playing was interrumped. Once we know the file, we can just navigate to the the file by means of the DvDplayer commands "$", " ", "X", ..., followed by "S" (and maybe " " to accept restart from the point last stopped). Please correct me if I am wrong.

If I am not wrong, then the last-played file can be found by looking for a file named "/tmp/hdd/volumes/HDD1/...." under /proc/<pid>/fd/, where <pid> is the process id of the DvdPlayer last created task.

Waiting for comments,
Best,

evr escribió:

George2005 escribió:Of course you are right, exactly, all the user timestamps will be lost by bookmark.db replacing - it is a disadvantage of that approach. However adding triggers into existing db file is possible only by using sqlite client/library call.

O.K. Everything clear for me now. Thanks!

Given the side-effects, I think the replacement approach will not be generally acceptable. So I guess we should forget about this idea and think in changing the current PM code (which invoques the sqlite3 binary) with direct calls to the libsqlite3 library...

Best,

Well, adding triggers into existing db file (using sqlite3 binary or libsqlite3 calling) is the best solution, actually, but as me and Victor have tested it this approach couldn't be reliable. I think the problem is that sqlite is serverless, so the db client works with db file directly (instead of communication with db server as usual in standard database environment). So in case of simultaneous access of DvdPlayer "native client" and sqlite3 binary (or libsqlite3) into db file there would be a conflict preventing the correct trigger adding.

evr escribió:

vic1972 escribió:more possible workaorund? I think it is very good we discuss the different approaches

O.K. Now that I seem to have understood what is all this "red button" and "bookmarks.db" buzz about I think there might be a relatively simple solution without touching bookmark.db at all.

If I have understood it well, the purpose of "red button" is to enable a single IR command to go back and play the file which was last being played before stopped by the user or by the DvdPlayer. Since DvdPlayer keeps the timestamp of the point where file was stoped, the only problem is to know which was last played file when playing was interrumped. Once we know the file, we can just navigate to the the file by means of the DvDplayer commands "$", " ", "X", ..., followed by "S" (and maybe " " to accept restart from the point last stopped). Please correct me if I am wrong.

If I am not wrong, then the last-played file can be found by looking for a file named "/tmp/hdd/volumes/HDD1/...." under /proc/<pid>/fd/, where <pid> is the process id of the DvdPlayer last created task.

Waiting for comments,
Best,

Well, you are right, there is no problem to find out the last-played filename at all, but the question is how to navigate to the right file in the filelist! As you know the filelist navigation is based on up & down arrows only so it is impossible to find the appropriate filename in the filelist by alphabetical manner !!! Eg the last played file has the name "StarWars_20110309_1200.ts" - ok, but how many "X" DvdPlayer commands (ie down arrows) should we send to find that file in the filelist? One, five, ten, fifty ... who knows

So we are creating the hardlink of last played file linking the " Repeat.ts", which is surely the first item in the alphabetical list of TS recordings and such "Repeat.ts" file is also "touching" (ie timestamping by the current date&time) to ensure that such file will be the first item in the list based on date&time sorting. And triggers in bookmark.db duplicate the timestamp of last played file into the " Repeat.ts" database record.
Well, it's quite complicated ... It would be more easily if it would be possible to "invoke" the last played file directly into DvdPlayer to just play it

George2005 escribió:Well, you are right, there is no problem to find out the last-played filename at all, but the question is how to navigate to the right file in the filelist! As you know the filelist navigation is based on up & down arrows only so it is impossible to find the appropriate filename in the filelist by alphabetical manner !!! Eg the last played file has the name "StarWars_20110309_1200.ts" - ok, but how many "X" DvdPlayer commands (ie down arrows) should we send to find that file in the filelist? One, five, ten, fifty ... who knows ;)

Well, I think it is easy:

If the file is in the REC directory and we access this directory via HOME --> Media --> Rec-List (I.e., the DvdPlayer cmnd "$"), files are shown sorted in descending creation-time order. We can just open the directory, get the file creation-times and sort them accordingly. Or maybe easier, let a daemon keep, in an auxiliary file, the list of files in REC along with their corresponding number of "X" commands needed to access them -- PM would then just need to read or grep this auxiliary file to get the mapping from filename to number-of-X's.

If the file is not under REC, or if we access it through HOME--> Media --> HDD1 --> REC, then DvdPlayer shows the files in alphabetical order and the we can find the number of "X" commands by alphabetically sorting the directory contents (which maybe is also easier if it is done by a daemon and registered into an auxiliary file).

Am I wrong?

Best,

evr escribió:

George2005 escribió:Well, you are right, there is no problem to find out the last-played filename at all, but the question is how to navigate to the right file in the filelist! As you know the filelist navigation is based on up & down arrows only so it is impossible to find the appropriate filename in the filelist by alphabetical manner !!! Eg the last played file has the name "StarWars_20110309_1200.ts" - ok, but how many "X" DvdPlayer commands (ie down arrows) should we send to find that file in the filelist? One, five, ten, fifty ... who knows

Well, I think it is easy:

If the file is in the REC directory and we access this directory via HOME --> Media --> Rec-List (I.e., the DvdPlayer cmnd "$"), files are shown sorted in descending creation-time order. We can just open the directory, get the file creation-times and sort them accordingly. Or maybe easier, let a daemon keep, in an auxiliary file, the list of files in REC along with their corresponding number of "X" commands needed to access them -- PM would then just need to read or grep this auxiliary file to get the mapping from filename to number-of-X's.

If the file is not under REC, or if we access it through HOME--> Media --> HDD1 --> REC, then DvdPlayer shows the files in alphabetical order and the we can find the number of "X" commands by alphabetically sorting the directory contents (which maybe is also easier if it is done by a daemon and registered into an auxiliary file).

Am I wrong?

Best,

Thanks for great ideas! But there are two complications:
1. There are 3 sort options in Recordings menu (1. by name, 2. by time, 3. by latest) and even it's not possible to detect which sort option is active
2. Victor and me have tested the possibility of sending amount of "X" commands to move thru the filelist, actually, but it is very sloooooow due the fact, that some "pause" time is needed between each "X" commands to assure a reliable function (see "SecondsInterleave" key in "StartRecordingPopUpManagement" section in PipeManagement.ini, whose value defines that pause time - default is 1 second). So I think is not quite acceptable for users to wait for example 100 seconds to move the 100th item in filelist

George2005 escribió:Thanks for great ideas! But there are two complications:
1. There are 3 sort options in Recordings menu (1. by name, 2. by time, 3. by latest) and even it's not possible to detect which sort option is active

Thanks for this info; I didn't know that! Where can I specify these options?

2. Victor and me have tested the possibility of sending amount of "X" commands to move thru the filelist, actually, but it is very sloooooow due the fact, that some "pause" time is needed between each "X" commands to assure a reliable function (see "SecondsInterleave" key in "StartRecordingPopUpManagement" section in PipeManagement.ini, whose value defines that pause time - default is 1 second). So I think is not quite acceptable for users to wait for example 100 seconds to move the 100th item in filelist

O.K. I had also thought about this possible problem, but didn't check it myself... You have done a lot of work on this issue; sorry for trying to reinvent the wheel! )

So, as I had said, for the moment I'll just change the PM code to run the sqlite3 binary without busybox. Later we can discuss implementing it with direct calls to libsqlite3.

Best,

evr escribió:

George2005 escribió:Thanks for great ideas! But there are two complications:
1. There are 3 sort options in Recordings menu (1. by name, 2. by time, 3. by latest) and even it's not possible to detect which sort option is active

Thanks for this info; I didn't know that! Where can I specify these options?

2. Victor and me have tested the possibility of sending amount of "X" commands to move thru the filelist, actually, but it is very sloooooow due the fact, that some "pause" time is needed between each "X" commands to assure a reliable function (see "SecondsInterleave" key in "StartRecordingPopUpManagement" section in PipeManagement.ini, whose value defines that pause time - default is 1 second). So I think is not quite acceptable for users to wait for example 100 seconds to move the 100th item in filelist

O.K. I had also thought about this possible problem, but didn't check it myself... You have done a lot of work on this issue; sorry for trying to reinvent the wheel! )

So, as I had said, for the moment I'll just change the PM code to run the sqlite3 binary without busybox. Later we can discuss implementing it with direct calls to libsqlite3.

Best,

Hi,
thanks for all your ideas, actually! It's nothing about "wheel reinventing", I am so glad to learn any new ideas!
So, in the Recordings Menu you can change the sorting option for filelist by green button.
Regards

George2005 escribió:[...]So, in the Recordings Menu you can change the sorting option for filelist by green button.

Thanks -- I had never payed attention to this before!

Best,

evr escribió:[...]I am waiting you finish with the new release before making my modifications to PipeManagement. Hope I can start soon [...]

Well, not that soon! but now I do plan to do it this week/week-end. Hope the SF version is up to date; otherwise, Vic please, update it or me know.

Best,

yes, svn is updated.
go ahead with any modification you would like to carry out.
regards

evr escribió:Well, not that soon! but now I do plan to do it this week/week-end. Hope the SF version is up to date; otherwise, Vic please, update it or me know.

vic1972 escribió:yes, svn is updated. go ahead with any modification you would like to carry out.

Done!

I've made a quick check and it seems to work exatly as before (but I am not sure that it worked perfectly well before...). I think you should test it more thorughly, though.

As far as I can tell, the use of "system()" in PipeManagement has been completely eliminated, except for the execution of a few service and custom scripts.

Best,