oztoppy Forum
Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment  
keith_leitch

Senior Member
Registered:
Posts: 742
Reply with quote  #1 
Hi: Are the watched-progress indicators in INFPlus read from .NAV files, or is there a separate database?
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 316
Reply with quote  #2 

I have not looked at this code for years, so I may be wrong.

There are 2 ways that progress during playback is indicated in INFplus.

  1. The "Current Programme" block.
  2. The little notch in the progress bar at the top.

Underlying both of these is the way that the firmware provides progress information.  Each recording has a total number of "blocks" and the TAP API reports progress using these "blocks".  For example, if a recording consists of 200 blocks and progress is at 50 blocks then you can deduce that the recording is 25% complete, or can you?

typedef struct
{
    byte    playMode;           // Playback Mode, refer TYPE_PlayMode
    byte    trickMode;          // Trick Mode, refer TYPE_TrickMode
    byte    speed;              // playback speed
    byte    svcType;            // 0 = TV, 1 = Radio
    word    svcNum;
    word    duration;
    byte    durationSec;
    byte    reserved;
    dword   currentBlock;
    dword   totalBlock;
    TYPE_File *file;
    TYPE_TapEvent   evtInfo;
    byte    repeatStatus;
    byte    reserved2[3];
} TYPE_PlayInfo;

Unfortunately, a block contains a variable duration of programme content due to the natural compressibility of various scenes.  For example, a totally black scene is highly compressible and a detailed mosaic is not.  Knowing the total blocks and the total duration only allows you to estimate the progress in time.

When INFplus writes an EPG record, it also takes note of the current block recorded, whereas the progress bar is an estimate using the method above.  This means that the "Current Programme" indicator and the progress indicator bar may be out of alignment.

I'm not sure if the firmware uses the NAV file to calculate the blocks because this information is also available for media files, and these do not have NAV files.

0
keith_leitch

Senior Member
Registered:
Posts: 742
Reply with quote  #3 
Thanks for this thorough explanation. I think it's safe to say that the NAV files aren't used, because of your comment about media files. I hadn't thought of that.

So when I stop a recording partway through, does your TAP record any data about its estimate of the progress? If so, where? I'm looking at the INFPlus screen on a stopped file now, and the "notch" is within the program right where I left it, so it doesn't seem like I have to play the file for a new calculation to occur.
0
keith_leitch

Senior Member
Registered:
Posts: 742
Reply with quote  #4 
I'll just give a little more detail about what I'm thinking. Now that my topfields have a connection to a NAS, I am trying to see if I can't get various TAPs to centralise and share information about play histories, progress, etc.

Based on DMC's description of INFPlus above, it may be that the information is based on an analysis of the recording, so it will probably just work. 

With TMSArchive, sharing playback progress seems to be a simple matter of sharing a text file with the other machines every time playback is stopped. These don't seem to depend at all on the files being in the same folder. However, sharing the last-played file probably won't work due to the mount-point creating a different root folder. That's no big deal.

With QuickPlay, I think that problem will be much more serious. I think everything it does probably depends on the files being located in exactly the same folder structure.
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 316
Reply with quote  #5 
Without external intervention, INFplus stores its additional EPG information using the inode of the INF file for the recording in question.  It assumes that you are recording to the local drive and that therefore the inode is guaranteed to be unique.
# pwd
/mnt/hd/DataFiles
# ls -laiF "Catalyst - Driverless Car.mpg"*
   4284 -rw-rw-rw-    1 root     root    2614903804 Sep 26  2017 Catalyst - Driverless Car.mpg
   4289 -rw-rw-rw-    2 root     root       565376 Feb 12  2018 Catalyst - Driverless Car.mpg.inf
   ^^^^--this inode!  ^--link count of 2!
   4288 -rw-rw-rw-    1 root     root      3407392 Sep 26  2017 Catalyst - Driverless Car.mpg.nav
# pwd
/mnt/hd/ProgramFiles/Settings/INFplus
# ls -laiF *4289*
   4289 -rw-rw-rw-    2 root     root       565376 Feb 12  2018 0000004289.INF
 184425 -rw-rw-rw-    1 root     root        53352 Jan  1  2000 0000004289.INF+
There is a hard link (same inode) to the recordings' INF file within the INFplus directory.  There is also an INF+ file that has a file name that is based on the inode of the INF that actually contains the additional EPG data.

I suspect that as you attempt to record to an external device, INFplus will try to make a hard link to a file on an externally mounted device that will fail because you can only make a hard link on the same file system.  This means that the INF+ file will be created, but that the hard link to the INF file will not be created.  When the housekeeping task runs, it will see an INF with a single link, assume that the original INF has been deleted and therefore clean-up the INF+ file.

Also, if a local recording has the same inode as a NAS recording, the INF+ data will be a mixture of both recordings.

INFplus has a feature called "Prepare for Archive" that copies the INF+ EPG data onto the end of the INF file so that it can be preserved.  This can only be done once a recording is complete.  There is also a setting that permits this to happen automatically once a recording is complete.  This allows INFplus information to preserved when a recording is archived or shared among PVRs.

0
keith_leitch

Senior Member
Registered:
Posts: 742
Reply with quote  #6 
Thanks. That answers my question. I think I'm reading that once prepared for Archive, each INF file has all the data necessary for any device playing back. Would it have to be prepared for archive on every device running INFPlus, though? Maybe not, if the INF file has all the necessary data in it.

What you said about hardlinks also may also explain some behaviours when I did experiment with external recordings. INFPlus activated, but didn't seem to be able to show me the various chunks of shows within the combined recording.

Just to clarify: I'm not planning to record externally. What I'm thinking about is trying to get multiple TAPs to coordinate their histories when playing the same file (for example, through mount-points created by TMSClient or NASMount.) This applies to TMSArchive and QuickPlay, too. So, if I play a file in the lounge room and stop it, I want the bedroom to know that was the most recent file played, and to show the same progress. None of this is by any means important; I'm just starting to think.
0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 316
Reply with quote  #7 
You only need to "Prepare for Archive" on the PVR that made the recording.

When you press the "Stop" button during playback, the firmware saves the current position (block) in the INF file.  I actually tested this when developing TMSServer/TMSClient.  I was able to stop playback on one PVR and then restart from another.

You will need to double-check this, I think that TMSArchive may have complicated matters when you change playback from PVR A -> PVR B -> PVR A, from memory, PVR A may start from where PVR A last stopped, not from where PVR B stopped.
0
keith_leitch

Senior Member
Registered:
Posts: 742
Reply with quote  #8 
Actually, back when I was talking to Tango, he took my suggestion and updated TMSA with an option to read playback position from the native INF file rather than from the TAP's database. For those of us who use multiple PVRs to play the same file, this resumes from the last-played position, wherever in the house that playback might have taken place. The only two (very minor) problems are that the progress indicators in TMSA do not get updated, and that the last-played file feature does not transfer from unit to unit. I've found a very simple text file that keeps a history of filenames to control this. They do not depend on any particular path, so a file with that name will have the same recorded last-play position regardless of what folder it's in. I've tested enough to prove that keeping the latest copy identical on every machine would solve this problem. I may add a cp to my polling script. 

INFPlus seems to be OK without any intervention once the .INF file is prepared.

QuickPlay seems impossible, though. As I guessed, it tries to keep a last-played list that includes folder locations, so moving its data file to another machine will do no good.

Most of this post pertains to TMSArchive, so I'll put a copy of it there.
0
keith_leitch

Senior Member
Registered:
Posts: 742
Reply with quote  #9 
I can confirm that INFPlus correctly displays the last resume position, even if that was set by a different Toppy. Brilliant! This makes sense if all is being read from the .INF file.

Quote:
Originally Posted by DeltaMikeCharlie

There are 2 ways that progress during playback is indicated in INFplus.

  1. The "Current Programme" block.
  2. The little notch in the progress bar at the top.



I think you mean that number 1 above is written into the .INF file when a recording is stopped. Is that right, or is it something visible that I'm missing?

I've noticed that the standard Info display (e.g. from the native file manager or from TMSArchive or quickPlay) often gives information for the second or third or fourth program recorded in a combined block. In other words, if I get SmartEPG to combine recordings from the same series, the default info is usually something other than the first recorded episode. It is not always the last episode in the block, either. Is this just a result of combining episodes, or is it a side-effect of INFPlus preparing for archive? I doubt there is a way for me to control it.

0
DeltaMikeCharlie

Mostly Harmless
Registered:
Posts: 316
Reply with quote  #10 
Quote:
Originally Posted by keith_leitch
I think you mean that number 1 above is written into the .INF file when a recording is stopped. Is that right, or is it something visible that I'm missing?

Both 1 & 2 are based on the information in the INF file.  However, the notch uses a linear interpolation to show progress (current block รท total blocks = fraction complete) and the current programme uses the INF block to lookup the INF+ data to determine which EPG event to highlight.
Notch & Block.jpg
Quote:
Originally Posted by keith_leitch
I've noticed that the standard Info display (e.g. from the native file manager or from TMSArchive or quickPlay) often gives information for the second or third or fourth program recorded in a combined block.
Hence the existence of INFplus.  From what I can tell, either the EPG data in the INF shows that lat full EPG event OR it show the last event for which the PVR received a "now/next" EIT packet.

0
keith_leitch

Senior Member
Registered:
Posts: 742
Reply with quote  #11 
OK, understood. I see now what you mean by "Block." Yes, you are right: I'm glad to have INFPlus as a way around the Info problem (as well as the other reasons).
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.