3 Fixes in seek functionality

[bridgem]

3 Commits:

1. config variable was accessed before initialisation in the case of a seek
2. In the loop that updates the display, the new position in the video is calculated and this value is written back to the db after the screen update. If a seek happens in the meantime, then that seek position is overwritten. I added a check to see if the db has changed in the meantime to prevent this.
3. The H:M:S values for the seek progress bar tooltip were incorrect. For example, the minute value would round up once the seconds passed 30.

[ Hope you're OK to take pull requests, and thanks for fixing my recent issue so quickly. Great project! ]

[robweber]

Thanks for the PR. That's an interesting edge case regarding the seek position that I hadn't run across before. The update process can take 1-2 seconds, depending on the display, so I can see how if your timing is right you'd encounter it.

This might sit open for a bit. I keep my VSMP on my desk at work and I'm away from the office for a few weeks. I'll run it there for a day or two to test the code and then merge this in.

[bridgem]

No hurry Rob, thanks for the response. Just thought I would push things upstream as I find them.

[robweber]

Finally got around to setting this branch on my main display. Going to let it run through the weekend as a test. Just going through the code it makes sense but want to confirm since it touches the logic for when progress is saved. Hopefully merge it all in soon. Thanks for the work!

[bridgem]

Thanks Rob. I must admit to only limited testing. I'm happy to work on it further if it doesn't pass

[bridgem]

I have found an issue with the seek/write logic when used in Directory mode.
If you seek to the end of the current video such that the next step would go beyond the end, the following happens:

1. At the next wake of the loop, the seek is recorded correctly by the logic which writes back the new seeked location (99.99%) and the video advances.
2. At the wake after that, the loop detects that it has now advanced beyond the end, and gets the next (2nd) file in the list (so far, so good). However, this time the 'next_pos' (which contains the seek from the end of the original video) is written to the last_played record of the new (2nd) video and saved to the database.
3. At the next loop, if the 2nd video is shorter than the previous, the program skips again to the next (3rd) video as pos is already beyond frame_count, thereby skipping a video. (If the 2nd video is shorter, it would seek to the same frame number as the end of the first video.

It needs a bit more investigation - I notice there are 2 checks of the frame count - which my code may not have taken into account properly:
"if(media_file['pos'] >= media_file['info']['frame_count']:"

[bridgem]

I have tested again on a fresh install of your code + my pull request. The seek functionality seems to work fine. I tested by seeking to the end of a video and the next refresh does indeed go to that start of the next video as intended. I can only think my comments above were on code which I had further changed.

[robweber]

Thanks for the work on this. I really like the QR code on the boot screen. Very useful. I made a few comments in the PR before I merge it all in.