playback position

[artmetz]

Something to consider. When I encounter a hang or crash, often the playback position isn't stored. Any chance it could be stored every 30-60 seconds so I don't have to figure out where the recording was at?
Art

[sub]

Yep - sounds reasonable.

[mvallevand]

Could you do this via a client API that nlite can use rather then brute force since the majority of UI clients are not crashing? I am very worried about the potential for database locks that will happen because of this largely unnecessary change.

Martin

[sub]

I don't see it as a work around for crash. I'd already considered adding this in the past, when I'd realised how good Netflix was at remembering approximately where you were up to, even if you powered off or killed it unexpectedly. That is a useful feature to have.

I'll have nextpvr.exe and UI clients it do it automatically, without the needs for the clients to add anything. I honestly don't think this functionality will cause you any issues, but if you want it, I can provide you a way to disable it.

[mvallevand]

The concept is fair but I have been noticing a definite increase in disruption to video playback when NextPVR does background tasks such as scheduling and starting recordings etc and having all Kodi pvr.nextpvr clients receive a lastupdated message every 30 seconds forcing a full recording list update, seems rather extreme. A database lock every 30 seconds is also risky for other reasons.

If it can optimized to perhaps handle the session is not responding, when a UI client sessions stops requesting x-activity during video playback then it makes more sense. Perhaps make NextPVR and nlite stop playback on exit (other than power off) can also help.

Martin

[BrettB]

The concept is fair but I have been noticing a definite increase in disruption to video playback when NextPVR does background tasks such as scheduling and starting recordings etc and having all Kodi pvr.nextpvr clients receive a lastupdated message every 30 seconds forcing a full recording list update, seems rather extreme.  A database lock every 30 seconds is also risky for other reasons.

I would agree that every 30 (or even 60) seconds seems a bit excessive as a "backup" option--particularly given the way NextPVR treats this as a "full update" to a recording's information. As purely a backup, I would be fine with it autosaving as infrequently as something like 5 minutes because resuming to that point, I could easily use the 1 minute skip forward to very quickly get back to where I was.

If it can optimized to perhaps handle the session is not responding, when a UI client sessions stops requesting x-activity during video playback then it makes more sense.    Perhaps make NextPVR and nlite stop playback on exit (other than power off) can also help.

This sort of an approach where you only update the database in a "known, bad situation" does seem like a better option and more in line with NextPVR's current philosophy about updates to the recording information.

[artmetz]

Just my 2 cents. I don't want to over complicate this, only suggest an approach for future consideration since database locks might be an issue.
I've had to deal with low priority/non critical database updates in past projects. One way to do this is to uncouple the request and place it in a low priority queue that was serviced at idle time or less frequently by a timer. In this case you only care about one (the last) request (maybe as a singleton).
Our queue was in the backend, so the client was only responsible for placing requests in the queue, uncoupling it from the database.
I don't know if you are familiar with design patterns, but there likely is one (or a combination) for this use case.

Seems like I also did this for logging so that the client wasn't I/O bound, but the entire log would be written out regardless of the client state.