"Include filesize with recordings" Creates Delays

[PRBUK]

I have around 1,000 recordings spread over many Windows Media Centre PCs whose directories are shared over a local Gigabit speed network.  I have added these (with the network filename) to the SCHEDULED_RECORDINGS table of Npvr.db3.  They all show and play correctly in the Kodi TV Recordings folder.

If I activate the "Include filesize with recordings" Kodi Npvr add-on option, Kodi pauses during start up at 75% "Loading Recordings from Clients" and generates significant network activity to every Media Centre device.  This can take some time (1-2 minutes) after which the EPG update is performed and Kodi startup is complete.

If I delete a recording from the recordings list, I get the 'rotating circles' for some time before the list is redisplayed without the now deleted recording.  I am 'guessing' that this is while all recordings are once again rescanned.

If I disable "Include filesize with recordings", both the delay at startup and after deletion disappears.

I would expect Kodi to only scan new recordings (existing recordings will not change size).

I turned on Kodi debug logging, along with component specific logging for SMB, libcURL, JSON-RPC, Video and PVR components.  I am not seeing any log entries to indicate hundreds of files being checked at startup/deletion.  I am seeing a constant stream of messages "DEBUG <general>: PVR::CPVRRecordings::UpdateInProgressSize: Updating recordings size" whilst Kodi is open and running.

I have turned off the option to include filesizes and everything is working fine - so this posting is more flagging the issue in case there is something I have missed.

Running the latest version of everything (Kod 19.1 / Npvr 5.1.4.210802)

I would appreciate your thoughts!

[mvallevand]

It is not the default for a reason and you have close to the worst case scenario with multiple drives and likely shares that need to be opened up. It could be worse if you were multi-user.

Unfortunately sub didn't want to add the file size to the scheduled_recording table so this is a brute force operation each time the recording_list is opened. For Matrix I did try and reduce the number of times it is called but it really should be used with a limited number of recordings and one storage drive.

Because those in progress recording updates your are seeing are so spammy I choose not to try and report back a growing file size. I considered it going to the file system every 1.5 seconds seems overkill.

Martin

[PRBUK]

Thanks for the explanation  - makes sense!  Presumably there is no option to store the data within a local Kodi database as an alternative? 

I had reset back to the default in any event, once I had figured out what was causing the issue!

Could you also please explain the purpose/values and performance implications for the two Chunk Size parameters (they are at their defaults!).  What is gained/lost by increasing/decreasing?

Great Add-On - Npvr and Kodi are a great replacement for Media Centre based on a few months of testing/development!

[mvallevand]

For the chunk size if it works leave them be. Based on comments on the Kodi forum specific cases require tuning but I leave it to users to investigate based on their seutp.

PVR recordings aren't stored in Kodi, unless they are played. Unless sub rethinks this there is no real solution. File size for me is typically not very important except when it and that is on bad or truncated recordings so I too would like to see it but I leave it off for now.

Martin

[sub]

Unfortunately NextPVR doesn't know the recording sizes, and it's time consuming to look it up, so not straight forward to supply this info to Kodi.

[mvallevand]

When I requested this change I asked for a row to be added to be populated at the end of the recording. I believe file size is already calculated since there is the zero size warning. Additionally I was asked to recalculated the duration since because of errors it is not always clock time. Since then you have added the duration check for VOD so I know it is possible.

Martin

[sub]

When I requested this change I asked for a row to be added to be populated at the end of the recording. 

Yeah, I got that. It was all the existing databases and recordings out there that were putting me off doing it.

I've implemented something like this for the next build though.

[mvallevand]

I understand it is a bit of work (why I asked in early beta) and is low priority. Now I guess we need it in recording.list XML for Kodi (Emby doesn't need it for JSON) plus the file based meta xml the recordings export and import XML

I will update my NextImport utility (now called NextTool) to populate the file sizes assuming I can use the ScheduledRecording Save() method.

Martin

[sub]

Now I guess we need it in recording.list XML for Kodi  (Emby doesn't need it for JSON) plus the file based meta xml the recordings export and import XML

Yes, I've added it in all those places

[PRBUK]

For the chunk size if it works leave them be.  Based on comments on the Kodi forum specific cases require tuning but I leave it to users to investigate based on their seutp.

Could you please describe what the settings are?  Is it a 'block' of data - so that Kodi requires 64 blocks to be received from the server for live and 32 for a recording before attempting playback?  Are these therefore buffer sizes?  Why is live double that of recording?  I like to understand what something is before changing and to understand why changing a parameter may address a specific issue.

Thanks