News:

Latest versions:
Server plugin: 0.5.1
MVP dongle: 0.5.2
Raspberry Pi client: 0.5.2
Windows client: 0.5.2-1

Main Menu

Mark watched recordings as watched

Started by glotzi, October 21, 2012, 20:02:34

Previous topic - Next topic

glotzi

Hi there,

it seems that vompclient does not mark or display recordings as watched in any way. This is a little bit annoying, because a have a lot of recordings for my kids and I can't distinguish between watched and unwatched recordings. Is this a bug or a missing feature?

MartenR

I think a missing feature, it was always like this on the mvp I think.

Marten

glotzi

Ok, I'm willing to implement this. Is the information whether a recording is watched or not, available on the client side?
I hope the protocal does not have to change.

MartenR

I do not know, a protocoll change is very likely.
But a thing, that I do not understand, vomp should transmit the current position for the resume position.
May be you can use this information, the protocoll should support this, but may be not in the recordings listing.

Marten

glotzi

Ok, I had a look into vdr source code and there the resume position will also be used for marking unwatched recordings.  I attached a git patch, which displays an asterisk behind all unwatched recordings. Marten, I hope you will accept it.

MartenR

Looks, ok at first sight, but it loads the info for every recording.
For raspberrypi this is probably ok, because we have a lot of memory.
For the mediamvp, that might be a problem.
Maybe do the following,

Check in isNew, if recinfo is already present before.
If not, drop the recinfo in the end.
But cache the result "isnew" and do not get a new recinfo from server,
if recinfo or a cache isnew is present.
In the moment you are getting the recinfo, everytime the list is drawn, this can be very often.

If you solve these issues, then I can include it.

Marten

glotzi

Ok, here 2nd try. You need both patches for applying.

MartenR

Sorry, you need also a second bool to indicate, if the isnew flag was previously loaded.
Your current implementation reloads the info every time.
The second thing is recinfo is declared static, so you must also check additional to recInfo != NULL, if recinfofor is equal to this.
See comment in header file.

Marten

glotzi

Quote from: MartenR on October 24, 2012, 06:00:56Sorry, you need also a second bool to indicate, if the isnew flag was previously loaded.
Your current implementation reloads the info every time.
I think reloading is prevented by loadRecInfo(). Plz have a look into it.

MartenR

But not if it is droped.
And still you need to check if it is the right recinfo, since it is a static member!

Marten

MartenR

Stop working at this feature.
I realized, that I have to change the protocoll anyway for the aac audio stuff, so I will add the is new flag as well to the protocoll, this weekend

Marten

glotzi

Thx for reply. Yesterday I didn't have the time for working on it, so no problem.

MartenR

I have look into this.
I will not implement it on the server side, since I do not see in the moment a way how to implement this without breaking the protocoll compatibility to older builds.
In the moment I try to not break protocoll compatibility, so this change has to come at a later development cycle.
And I do not like the idea that the recording info is fetched for every recording, as you did it in your patches. (Mostly my concerns are for the mvp plattform)

So from my side I do not want to include it, it is too much hassle for such little feature.
May be later...

Marten

glotzi

Bad to hear  :(.

So I will add the patch to my private patchset.

Chris

This feature is now implemented on the 0-4-0rc branch of the git repo. It changes the client server protocol so if you try it you will need to match server and client versions.