ServerStatus.scantime is updated after every browse by folder, even if nothing changes

[kaaholst]

Expected result
The lastscan property as reported by serverstatus should only be updated when a scan completes, and preferably only if there actually was a change.
Additionally, if it would be nice to be able to detect if a full rescan has been performed, i.e. the lastscan value is from a full rescan.

Actual result
The lastscan property of serverstatus gets a new value every time a folder is opened. This can be verified at least using any Jive based controller, e.g. a Radio.

[michaelherger]

Scanning is an important part of the Browse Music Folder feature. If you don't want LMS to update content from folders you're browsing to, use Browse Filesystem instead. You might have to enable it in the Extended Browse Modes plugin.

[kaaholst]

Thanks for the quick response!

The idea with this issue is to submit a bug report. Not to solve an issue with a specific LMS setup.

I certainly want to update the music library with content from the media folder, but are expecting this to happen on a library scan, not when browsing the folder in everyday use.

The problem with the scantime being updated when browsing by folder, is that changes in the scantime are used to trigger rebuild of the client side caches on LMS clients. Some users prefer to browse their library by folder, which means that those users will have the client side cache rebuild very often, thus making a client side cache basically useless. Note that this will happen even if the browse by folder is done on another client than the one with the client side cache.

Note also that this not a major issue, it can be worked around on the client(s). This report is mainly meant as a possibility to improve LMS.

[michaelherger]

The idea with this issue is to submit a bug report. Not to solve an issue with a specific LMS setup.

This is not a bug, it's a feature. And I didn't "solve an issue with a specific LMS setup", but tried to explain how to use that feature, and what to do if you don't want to use that feature.

You can browse folders without having them scanned. Exactly what you want. See my previous comment.

[kaaholst]

Thanks for the suggestion. However, a solution, which requires setup, is not good enough. Most users wouldn't understand how choosing between “Music Folder” and “Disks and folders” in “Additional Browse Modes” relates to scantime or client side caches. Nor be able to find that setting.

Still possible solutions could be.

1. Why is scanning an important part of Browse Music Folder, instead of only when performing a library scan?
2. If scanning for some reason must be done when browsing folders, it shouldn't update scantime.
3. If backwards compatibility with the scantime property must be preserved, a new property which hold the latest time there actually was a change.

[michaelherger]

Thanks for the suggestion. However, a solution, which requires setup, is not good enough. Most users wouldn't understand how choosing between “Music Folder” and “Disks and folders” in “Additional Browse Modes” relates to scantime or client side caches. Nor be able to find that setting.

"Most users" claims are difficult 😉. Because "my" most users don't have this problem. They don't use Browse Music Folders, or they don't care about a timestamp somewhere. As you are the first to complain about the current behaviour I must assume that this is no problem for most users. And the minority has a solution. A solution which admittedly requires some configuration. But it's there. Just use it.

1. Why is scanning an important part of Browse Music Folder, instead of only when performing a library scan?

Because most users don't want to run a scan with all its overhead just to listen to the latest album they added. They browse to the folder, play it. And magically the album now is part of the collection.

2. If scanning for some reason must be done when browsing folders, it shouldn't update scantime.

I think this claim raises an important question: is the scan time always updated, even if nothing changed? Then that might indeed be considered an issue and worth some investigation. scantime should only be changed if something about the collection changed. I'd agree with that.

Could you please change the issue's title accordingly if that was the actual problem here?

3. If backwards compatibility with the scantime property must be preserved, a new property which hold the latest time there actually was a change.

Are you a frontend developer dealing with the situation? Do you see user complaints about the behaviour, or are you worried by the potential performance loss? I'm wondering what data should even be cached client side (beyond eg. artwork), as there are parameters other than the scan time which can have an impact on eg. an artists or albums list. There are preferences which can influence whether an artist is supposed to be shown in an artists list or not without having to rescan the library (eg. based on their role).

[kaaholst]

Sorry, I'm the maintainer of the Squeezer Android client. Apologize for not mentioning that in the first place!

1. Why is scanning an important part of Browse Music Folder, instead of only when performing a library scan?

Because most users don't want to run a scan with all its overhead just to listen to the latest album they added. They browse to the folder, play it. And magically the album now is part of the collection.

I would expect most users to look for the new album via the Albums or Artists lists or similar. Maybe a solution using something like Inotify is better.

2. If scanning for some reason must be done when browsing folders, it shouldn't update scantime.

I think this claim raises an important question: is the scan time always updated, even if nothing changed? Then that might indeed be considered an issue and worth some investigation. scantime should only be changed if something about the collection changed. I'd agree with that.

Could you please change the issue's title accordingly if that was the actual problem here?

Yes, it's updated even if nothing changes (.e.g open the same folder multiple times). I'll update the title.

3. If backwards compatibility with the scantime property must be preserved, a new property which hold the latest time there actually was a change.

Are you a frontend developer dealing with the situation? Do you see user complaints about the behaviour, or are you worried by the potential performance loss? I'm wondering what data should even be cached client side (beyond eg. artwork), as there are parameters other than the scan time which can have an impact on eg. an artists or albums list. There are preferences which can influence whether an artist is supposed to be shown in an artists list or not without having to rescan the library (eg. based on their role).

Yes, I'm the maintainer of the Squeezer Android LMS client. The client offers the possibility to long press a Jive item to have it added as a shortcut on the home screen. When the shortcut is selected, we will issue the same command as the original item. This works as long as the internal ID's in LMS doesn't change. Therefore, we have implemented a search for those shortcuts when the lastscan time changes. This is a slow process, but it's ok as long as it doesn't happen too often. We also have an artwork cache, which is flushed when the scantime changes. We haven't had any complaints about that.

I agree, most users don't care about this. However, the users which like to have a shortcut to a music folder on the home screen, are also likely to browse by folder.

I just thought this it was an easy fix, if the scanning on browse by folder was just some old behaviour which existed for no particular reason.