Best iPad App for MinimlServer

[stefano_mbp]

It’s not as you say, sorry: Rescan just issues a rescan to Minimserver.
In fact, some complaints concern the fact that no progress of the Minimserver rescan appears so that an update can only be done when the rescan is finished

[stefano_mbp]

… after a rescan you’ll see in the folder view of Lumïn app new added and modified album/tracks but no update is done to the Lumïn app db
the icons highlighted in red work on the internal Lumin database while the one in yellow acts directly on Miniserver (folder view)

[Donuk]

Yes,
Stefano is correct...
"
- Rescan - issues a library rescan to Minimserver, without updating Lumïn app db
- Update - after a Minimserver library rescan it just update the content of Lumïn app db with new/modified albums/tracks
- Reload - it delete the Lumïn app db and reload it from scratch from Minimserver
"
I do not use Update myself, preferring Reload - that way you can watch the progress of the Lumin app reading the library.

Donik

[Peter@57m]

Lumin re-indexing issue

I posted to Lumin the issue described by myself and @simbun earlier in this thread where the Lumin app was re-indexing even when there were no changes when a tagUpdate file was present.

Peter Lie, Lumin firmware lead, tried to reproduce this problem but he could not. He tried on Windows and @simbun had said Windows was not a problem so I was going to just reply saying to try with MinimServer on a Linux system.

However I though I'd try it again myself first. So I added the tagUpdate file back to both my Melco and QNAP instances of MinimServer and did not have the Lumin app re-indexing.

I tried with Lumin on ios and android both of which have been updated since the last time I tried this. Given that Lumin could not reproduce the problem I assume they did not attempt to fix the issue with these updates. MinimServer was at update 248 both times.

So I am at a loss as to why the problem no longer exists.

@simbun: could you try to reproduce this on your system with the latest versions of the Lumin app.

Peter

UPDATE: should have said the latest Lumin app versions are iOS 9.2.1 and Android 6.2.0

[simbun]

(25-03-2024 12:50)Peter@57m Wrote:  I tried with Lumin on ios and android both of which have been updated since the last time I tried this. Given that Lumin could not reproduce the problem I assume they did not attempt to fix the issue with these updates. MinimServer was at update 248 both times.

So I am at a loss as to why the problem no longer exists.

@simbun: could you try to reproduce this on your system with the latest versions of the Lumin app.

I'm still having the issue with Lumin 6.2.0 running against MinimServer on Linux and Windows.

I did spend a bit of time looking at this over the weekend, but I couldn't get Lumin to behave consistently enough to be able to narrow it down. I know it's not directly related to tagUpdate as I can reproduce it without that.

I've been most succesful in inducing the behaviour by adding an album with a GROUP tag (album counts then differ between MinimServer and Lumin), although that doesn't explain what happened when I pulled tagUpdate from my prod environment.

If you can't replicate it by using a Group tag then I should be able to pull something together for you to test with.

[Pepsican]

(25-03-2024 12:50)Peter@57m Wrote:  Lumin re-indexing issue

I posted to Lumin the issue described by myself and @simbun earlier in this thread where the Lumin app was re-indexing even when there were no changes when a tagUpdate file was present.

Peter Lie, Lumin firmware lead, tried to reproduce this problem but he could not. He tried on Windows and @simbun had said Windows was not a problem so I was going to just reply saying to try with MinimServer on a Linux system.

However I though I'd try it again myself first. So I added the tagUpdate file back to both my Melco and QNAP instances of MinimServer and did not have the Lumin app re-indexing.

I tried with Lumin on ios and android both of which have been updated since the last time I tried this. Given that Lumin could not reproduce the problem I assume they did not attempt to fix the issue with these updates. MinimServer was at update 248 both times.

So I am at a loss as to why the problem no longer exists.

@simbun: could you try to reproduce this on your system with the latest versions of the Lumin app.

Peter

Did IOS and Android update? Not all changes are in the release notes. And perhaps an update simply reset a parameter or trigger.

[Peter@57m]

(25-03-2024 14:52)simbun Wrote:  I've been most successful in inducing the behaviour by adding an album with a GROUP tag (album counts then differ between MinimServer and Lumin), although that doesn't explain what happened when I pulled tagUpdate from my prod environment.

If you can't replicate it by using a Group tag then I should be able to pull something together for you to test with.

I'm not familiar with the Group tag as its not something I use.

If you can provide something I'm happy to test it on Melco and QNAP

[Pepsican]

My favourite iPad app is mConnect. Automatic Tidal integration and sees MinimServer.

[simbun]

(25-03-2024 17:48)Peter@57m Wrote:  I'm not familiar with the Group tag as its not something I use.

I think it's meant primarily for classical Works (look at the albums Help! and Rubber Soul).

(25-03-2024 17:48)Peter@57m Wrote:  If you can provide something I'm happy to test it on Melco and QNAP

With a default MinimServer profile, set the content directory to '2009 - The Beatles In Mono' then restart MinimServer. In Lumin you should see that MinimServer shows 11 albums whilst Lumin states 13. If you close and reopen Lumin you should see a lot of activity in the debug log (given the limited number of albums).

If you remove CD05 (Help!) and CD06 (Rubber Soul) and perform a MinimServer rescan, MinimServer and Lumin should now both show 9, and you should see a lot less processing when reopening Lumin - although I'm sure I've seen much less before.

Could you not ask Lumin for a toggle to turn it off

The file is a little big for the MinimServer forum so I've uploaded it. It's the Beatles 2009 boxset, without the audio, that I've been testing with on Windows.

EDIT: SHA1 - 34cb6fd6f662075a08d646134295266df4d84845

[Peter@57m]

(25-03-2024 19:12)simbun Wrote:  With a default MinimServer profile, set the content directory to '2009 - The Beatles In Mono' then restart MinimServer. In Lumin you should see that MinimServer shows 11 albums whilst Lumin states 13. If you close and reopen Lumin you should see a lot of activity in the debug log (given the limited number of albums).

If you remove CD05 (Help!) and CD06 (Rubber Soul) and perform a MinimServer rescan, MinimServer and Lumin should now both show 9, and you should see a lot less processing when reopening Lumin - although I'm sure I've seen much less before.

Could you not ask Lumin for a toggle to turn it off

I can reproduce what you are seeing and Lumin consistently does a re-index until those albums are deleted.

I will continue to have a play to see if I can isolate what's going on.