Constant database updates and disk writes

[cleoold]

Jellyfin works very great for me except some minor annoyances that bug me a lot of time. When I play music (e.g. on the Web UI), I observe that my disk is constantly written with something like 10-20KB/s, even when the music is paused. I found these files are modified every 10 seconds:

• library.db
  
• library.db-shm
  
• library.db-wal
  
• jellyfin.db-shm
  
• jellyfin.db-wal
  

(surprisingly jellyfin.db was not updated that often) I confirmed it because every time I listed the directory they always had modified date as current time.

I saw these logs every 10 seconds too after turning on the debug logging:

Code:

[05:57:13] [INF] [25] Microsoft.AspNetCore.Hosting.Diagnostics: Request starting HTTP/1.1 POST http://xxx/Sessions/Playing/Progress - application/json 527

[05:57:13] [INF] [25] Microsoft.AspNetCore.Cors.Infrastructure.CorsService: CORS policy execution successful.

[05:57:13] [INF] [25] Microsoft.AspNetCore.Routing.EndpointMiddleware: Executing endpoint 'Jellyfin.Api.Controllers.PlaystateController.ReportPlaybackProgress (Jellyfin.Api)'

[05:57:13] [INF] [25] Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker: Route matched with {action = "ReportPlaybackProgress", controller = "Playstate"}. Executing controller action with signature System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.ActionResult] ReportPlaybackProgress(MediaBrowser.Model.Session.PlaybackProgressInfo) on controller Jellyfin.Api.Controllers.PlaystateController (Jellyfin.Api).

[05:57:13] [INF] [25] Microsoft.AspNetCore.Mvc.StatusCodeResult: Executing StatusCodeResult, setting HTTP status code 204

[05:57:13] [INF] [25] Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker: Executed action Jellyfin.Api.Controllers.PlaystateController.ReportPlaybackProgress (Jellyfin.Api) in 0.5583ms

[05:57:13] [INF] [25] Microsoft.AspNetCore.Routing.EndpointMiddleware: Executed endpoint 'Jellyfin.Api.Controllers.PlaystateController.ReportPlaybackProgress (Jellyfin.Api)'

[05:57:13] [INF] [25] Microsoft.AspNetCore.Hosting.Diagnostics: Request finished HTTP/1.1 POST http://xxx/Sessions/Playing/Progress - 204 null null 1.1624ms

Ouch, they don't show DB though. I may believe it's monitoring the playback progress and somewhat storing it to the db (for group play purpose?). Given I use direct play to avoid transcoding on hard drives, My question is can I further disable these playback-related disk writes, so I get ZERO disk writes when issuing read-only ops (i.e. direct playing media) to save my drives (I'm kind of paranoid when it comes to storage longevity lol)? Is doing the logging a must, or some important things will break?

Same for activity logs: I got concrete answer from GH issues that it (or part thereof) cannot be disabled.

I'm a bit tech-oriented, so if either cannot be done of out the box, can anyone give me pointers on where I should look to modify the code myself?

PS: blocking requests from browser to /Sessions/Playing seems to do some job by removing the tiny writes, but does not feel right to me so configuring the server is preferred.

[TheDreadPirate]

There is no config for disabling playback progress tracking.  This is used for scrobbling, which some clients use but not all.

An example from Feishin (desktop music player).

   

The same endpoint you are blocking would also affect video progress tracking.  If you stopped half way through a video it would not appear in "Continue watching".

[cleoold]

There is no config for disabling playback progress tracking.  This is used for scrobbling, which some clients use but not all.

An example from Feishin (desktop music player).



The same endpoint you are blocking would also affect video progress tracking.  If you stopped half way through a video it would not appear in "Continue watching".

I noticed that blocking Sessions/Playing/Progress endpoint alone does not change the "scrobbling" or transcoding behaviour - and video playback can still be continued from where it is closed - except when you abruptly close the browser so Sessions/Playing/Stopped cannot get to the server to update status, but that'll be the same with Sessions/Playing/Progress too.

Is there another use case for this call? And btw this seems like a good use case for an in-memory data store.