Bug #1229
closed
VideoFE should save the current playlist item before it starts, then clear it after it ends that video.
Added by Hammel about 2 months ago. Updated 30 days ago.
100%
Description
This will allow AutoKiosk to restart where it left off.
This feature could be specific to AutoKiosk.
Related issues
Updated by Hammel about 1 month ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
This should be not just the filename (sans path, because it could move with multiple USB sticks) but the offset into the video.
Updated by Hammel about 1 month ago
This should be done in dbkiosk.c:kioskGetStatus() after right before exiting the function. It should call a new function, saveState(kioskActiveVideo, position), to keep track of state of video and position.
However, kioskGetStatus() is called 4 times a second. To reduce wear on the SD card the writes should only happen once every 5 seconds. Being within 5 seconds on restart is really not something humans would care that much about - it's what happens on streaming services currently.
Given that the metadata is saved, it should be used when videofe starts. It will first have to make sure the video that was playing is still available. This means it will need to save more than just the title because there can be more than one video with the same title.
In Kiosk modes a hash should be stored to better identify the file to run. See RM #1231 for details on how scanning generates metadata in kiosk mode.
In Player modes the JSON data could be used since it has a unique identifier in the filename that is also in the JSON file. So just store the filename, which looks just like an ordinary uuid. That will identify the metadata for the video which includes the videolib.title and videolib.path, the latter relative to the videolib JSON file.
Updated by Hammel about 1 month ago
- Blocks Bug #1231: Scanning for videos should be done in the foreground for /media/usb and background for /media/smb. added
Updated by Hammel about 1 month ago
- % Done changed from 10 to 20
dbkiosk.c has been updated to use a data structure for the GSlist of movies it finds. The structure includes filenames and a SHA1 hash for the file. The data amount used for the hash is just 1024x1024 so that hash is pretty weak. But it's just a test for now.
dbkiosk.c has also been updated to use the find command better by searching just for files with supported suffices.
These changes have been tested compiled. They need to be tested on an AutoKiosk system (or Kiosk, I suppose) to make sure things function just as before, without utilizing the hash for saving the data.
Updated by Hammel about 1 month ago
- % Done changed from 20 to 30
Saving and loading status in kiosk mode is implemented and test compiled okay.
Next: in dbKioskLoad(), if kioskSavedVideo != NULL, search for the kioskSavedVideo hash match and, if found set it to the kioskActiveVideo. Whether found or not, the kioskSavedVideo entry should be cleared.
Also: when starting the video in startKiosk(), right before kioskStartStatusTimer(), call a function to set position of the just started video.
By doing this before the status timer starts the timer will pick up the new status after the video has already moved to the saved position.
For this to work, I'll need to place the saved position in the kioskActiveVideo entry and then, when it's used to set the position, it should be cleared.
Update¶
A better solution:rename kioskStartStatusTimer to kioskStartTimerschange startKiosk() to call just kioskStartTimersmove kioskStartNextTimer code into kioskStartTimers, with the usleep() from startKiosk() moved there too.Add the test for non-zero position in kioskActiveVideo to the start of kioskStartTimersIf non-zero, send the position request to omxplayer, then clear the position request.
This is as close as we can get to setting the position of the video to the point of starting the video. And it doesn't interfere with normal video playback in Media or Player systems.
One problem: the write of the saved metadata is not atomic nor is it guaranteed to complete before videofe exits. With reboot -f the write could be partial. I need to check this. It's possible the journaling in the ext4 file systems will handle this for me.
Update 2¶
I added shutdowns for the kiosk timers including the one that handle writing the metadata. So this will allow flushing the write before the app exits as long as it exits normally. Reboot -f may still be a problem, though catching the reboot -f at exactly the moment the write is happening would be highly unlikely.
Ready for testing on hardware.
Updated by Hammel about 1 month ago
- % Done changed from 30 to 60
Tested on hardware. Found a number of crash bugs and fixed them.
Once saving of the status file is running, it looks like this:
{"filename":".\/sda1\/bailey\/Rebabaileycody-003.mp4","position":"59558530"}
Issues with this:
- The hash value is missing.
- The filename includes the path. It shouldn't.
I haven't tried to reload because of the missing hash.
Updated by Hammel about 1 month ago
This is fixed but there is another problem. The position for the video is being sent over DBUS before the video has been started. So instead of sending this where it's currently being sent which is from kioskSetTimers():
kioskSetPosition[dbkiosk.c:274] INFO Sending DBus notification: /usr/bin/dbuscontrol.sh setposition 4388302ll
It needs to be sent right after the video is spawned in playerProcessor(). For this to work the KIOSK_T pointer needs to be propagated to spawnPlayer() instead of just the filename.
To do this, startPlayerProcessor() must be called with the KIOSK_T, but that function is called from both dbkiosk.c and db.c, and the latter doesn't use KIOSK_T. I might be able to compile based on a -DKIOSK option, but if not I may need a different API for the player.c functions just for Kiosk's.
Updated by Hammel 30 days ago
- Status changed from In Progress to Closed
- % Done changed from 60 to 100
Okay, this is working now. It's not ideal because the video will start playing immediately and it takes a second or two before the position request is transferred, but it does get sent and the video is repositioned correctly. Or mostly correctly. The saved value seems to be a little ahead of the displayed video for some reason. But it's close enough for now.
An alternative, which I don't intend to implement just now, is to use the -l option to omxplayer. That requires converting the position, which is in microseconds, to HH:MM:SS.
Code tested on both Kiosk and Media Systems and is working as expected.
Code committed and pushed.
Closing issue.