Universalmediaserver: Don't actualize "Shared folders" while scanning after a server restart; it's need a UMS restart.

[rd1]

default list is all drives.

i add 1 local partition D: , press restart server, reset cache then scan (magnifier icon), it still scans C: drive.

close ums and relaunch it for changes to take effect.

[dogancelik]

I had a similar problem.

This is what happened in my case:

1. Default is All drives, I can't remove it so I add E:\Music to get rid of it.
2. Start the scan
3. It still scans C: drive, D: drive.

Same stuff happens when I remove E:\Music:

1. Shared folders list only has one item and that is: E:\Music
2. Remove E:\Music so it's back to default again: All drives
3. Start the scan
4. It still scans E:\Music first.

OS version: Windows 7 64-bit
UMS version: 5.1.4
Java version: 8 update 51

If you close UMS and start again, shared folder scan works correctly. So it doesn't update your shared folders list unless you restart the program.

This issue still persists in the latest version of UMS (5.2.1)

[SubJunk]

Seems like a bug, but for the record there is no need to manually scan. The cache is automatically populated when you browse.

[Nadahar]

@SubJunk It's not a bug, I've noticed the same behaviour and have in the back of my mind to try to find a more inituitive way this could be handled. What happens is: When you add or remove folders, the "restart server" goes green. It's not very easy to notice imo, but the changes aren't actually "saved" until you press restart server. If you then click scan, it will scan all the folders, not just the new ones. If you press scan before "restart server", it will scan the list as it were before it was modified.

About browsing to populate: I guess that depends on the use case, but when you have thousand of music files you don't want to have to browse them all to get them scanned and categorized by artist, album, title etc.

[SubJunk]

@Nadahar okay so maybe we should make it more obvious that a server restart is required

The iTunes integration data doesn't get cached anyway, so it doesn't make a difference for those folders.

[Nadahar]

@SubJunk Yes, as a minimum. Disabling (gray out) the scan button from any path is changed until restart would probably also be smart, and the tooltip for the scan button should probably also change to explain why it was disabled and that a restart was required. But, the elegant solution would be to figure out if the server really needed a restart, or if it was a way to reinitialize only what was needed to avoid having to restart, and then automaticly start a queued scan for added folders?

I didn't think of ITunes, but if you have a large collection og media on disk like many people do.

[dogancelik]

@Nadahar what you described in your first post is a bug.

• If you press green "Restart Server" button then press "Scan all shared folders", it doesn't scan new folders.
• If you don't press green "Restart Server" button then press "Scan all shared folders", it still doesn't scan new folders.

Either way it doesn't scan new folders.

To devs: I want to know why this function requires restarting application at all.

[Nadahar]

@dogancelik When I test it it doesn't require application restart if you press the green "Restart Server" button after modifying the folder list but before you click "Scan". If will then scan all shared folders, including the newly added (if any are added). There's no way to get it to scan _only_ the new folders.

If you experience that it doesn't scan the new folder(s) also when doing this, you're experiencing different behaviour than I do. Make sure UMS logs at debug level (on the Logs tab) and click scan after pressing "Restart Server". If you then open "debug.log" you can see all that's happened, and which folders that are scanned.

EDIT: When I tested it yesterday it found that it scanned the new folders after restarting the server, but when I test it now it doesn't - I actually have to restart UMS. Definitly seems like a bug in addition to being confusing.

[dogancelik]

@Nadahar I didn't say _only_.

I simply have one item in my Shared Folders list. In my test, it's either some random folder or my music folder in some other drive.

• If I remove a random folder and add my music folder, press green restart server, it doesn't scan my music folder (even though that's the only thing in my shared folders list), it scans that random folder instead.
• If I remove my music folder and add a random folder, press green restart server, it doesn't scan my random folder (even though that's the only thing in my shared folders list), it scans my music folder instead.

I don't know how many times I have to repeat this.

I set the log level to all, checked the logs, there is nothing informative there.

Edit: as @Nadahar pointed out, you have to open debug.log to see all messages. going to test again and see if I can find anything useful in debug log.

Edit 2: After I remove a random folder and add my music folder, it doesn't tell anything about E:\Music being added to Shared List under debug.log.

[Nadahar]

@dogancelik In my edit I said that I agree that when I test it now you have to restart the application to register the changes. I don't know if messed up my test yesterday or if it's a bit "random", but that's why I said it's definitly a bug in my edit.

My comment about only scanning the new folder was simply that I think that's what you usually would want when you add a folder, and that doesn't seem possible to do without scanning everything.

When it comes to the log, you have to actually open the log file - the logging in the "Logs" window is filtered to just show info, warn and errors and doesn't show debug messages. In the bottom right corned of the "Logs" tab you have a button Open full debug log which will open the actual file with the debug messages.

I have no idea about the problem scanning images, and I think that should be reported as a separate issue.

[dogancelik]

@Nadahar I didn't realize it would not show them under program itself, thanks for letting me know. I'll open another issue.

[rd1]

hello, did you not read the OP ? i said:

back in june just when the devs removed the save button in the version of ums :

default list is all drives.

i add 1 local partition D: , >>>>>press restart server, <<<<<< reset cache then scan (magnifier icon), it still scans C: drive.

close ums and relaunch it for changes to take effect.

the only true way to get the scan function to scan where i want it to, is to exit ums then start it from scratch.

that is the bug, when clicking save and then clicking "Restart server" in green, it did not scan where i entered the path, it scans "all drives" regardless.

Another bug: when adding paths to scan with the browse box, it doesn't even go in the subfolder when you double-click a folder to go into. What is that ... it doesn't seem standard windows material to me.

[Nadahar]

Another bug: when adding paths to scan with the browse box, it doesn't even go in the subfolder when you double-click a folder to go into. What is that ... it doesn't seem standard windows material to me.

It isn't standard Windows - it's Java. I've been annoyed by that browse box as well, most of the times I want to open a folder it puts me in rename mode - or nothing happens. Something is off with the doubleclick speed, but I doubt that's under UMS' control.

[rd1]

i have other java programs, they work fine.

i am using java v7.58 btw

upgrading to 8.45 wouldn't be the worst thing in the world but would ums function properly ?

[Nadahar]

i have other java programs, they work fine.

I was referring to the browse dialog only, I think that's usually pretty messy in Java applications. I don't know if upgrading Java would make any difference, probably not.

[rd1]

me too i was refering to that browse dialog only.

idk about how they handle windows browse functions but it shouldn't bug like that. idk, but i'm sure something can be done to simplify adding paths, maybe allow to paste them into the program in a text box.

better yet: export in text file then import after re-installing.

if we do a clean install we loose these paths. that would be a good idea to add import/export paths.

[SubJunk]

@rd1 you should probably upgrade Java for security reasons, I doubt it will make a difference to this

[Nadahar]

This bug is old, I just checked out UMS 1.1.0 - the bug is there. I also checked out PMS 1.9.0 - and the bug is there as well.

[SubJunk]

Yeah it is super old, I don't think there has been a version of PMS or UMS that doesn't have the bug. I'm finding that part of the code pretty complicated to figure out and fix but I'll keep looking at it

[Nadahar]

@SubJunk I looked at it a little bit and can't see that it should be very hard to fix, it doesn't actually seem like a "bug" in the sense that there's something not working as intended, it simply seems to me like this was never made.

I think fixing this would fall naturally together with redesigning 6.0.0 for per share fully played action since it touched much of the same code, and I can have a go at it as soon as I've submitted the small fixed I'm working on for 5.x.

[SubJunk]

@Nadahar that sounds promising, I'll see what you come up with :)

[Sami32]

@Nadahar Any news on that ?

[Nadahar]

@Sami32 No, I abandoned my projects early this year when it became apparent that I was wrong to modify "someone else's code". Imo the whole configuration of shared folders and especially monitored folders is a mess and should be mostly rewritten AFAICR. This is impossible to do without stepping on toes though.

[Sami32]

@Nadahar OK, so i will try to check and see what patch could be done, my way, with my possibilities.

AFAIK it was working in 1.00 PMS version (december 2008) but not anymore in 1.03 version (2009).
After that, they just leaved the users restart UMS.
It's look like it affect the users using UMS as a service, as they need to shutdown and restart UMS service, as answered by one developper from that era.

[Sami32]

I finally put my nose in.
Here is the culprit commit: https://github.com/UniversalMediaServer/UniversalMediaServer/commit/f478c88a6033edbb2f66a735a766ac53e89e85f0

That is a very vicious one :)

[Nadahar]

@Sami32 It's not obvious to me how f478c88a6033edbb2f66a735a766ac53e89e85f0 could have had any impact on shared folders not refreshing. Are you sure it's this one? Do you have idea of what in f478c88a6033edbb2f66a735a766ac53e89e85f0 that causes the bug?

[Sami32]

@Nadahar Yes, because i tested it.
I didn't search more, though i've an idea, as skilled coder are around.
I just search and report it, that's all. That's where i get fun, after that i'm not very interested to go further.
Who said that the commiter should solve it ?

[Sami32]

@Nadahar You'll get a more obvious colorfull perspective ;-)
https://www.diffchecker.com/XBYjaeA5
https://www.diffchecker.com/nBUaxH4n

[Nadahar]

@Sami32 Have you pasted the wrong SHA? The changes you link to look relevant, but those are not the changes from f478c88a6033edbb2f66a735a766ac53e89e85f0.

[Sami32]

@Nadahar It's the difference with the precedent commit from @SharkHunter that work fine before the @SubJunk commit.
I'm done with it now.

[Nadahar]

@Sami32 I'm just trying to understand what you mean. As far as I can tell, you think that the problem is somewhere between da67bb7869ad796d2755e85eabad5410d2ee9c98 and f478c88a6033edbb2f66a735a766ac53e89e85f0..? The problem is that those two aren't adjacent to each other, there are other commits in between, or: They are actually in different branches.

f478c88a6033edbb2f66a735a766ac53e89e85f0 was in master at that time, while
da67bb7869ad796d2755e85eabad5410d2ee9c98 was in the 5.0.0 branch. You can't really compare them directly. My bet would be that 5.0.0 broke this.

[Sami32]

@Nadahar I just point out the commit where this bug appear, i'm not competent to say anything else.
It's up to skilled coders.

Thanks for you input.

[Sami32]

@Nadahar That's said i don't understand what you mean, as we really don't see/work the same, but that doesn't really matter on that as i'm not interested more than that.

Perhaps you should look at that one instead ?
https://github.com/UniversalMediaServer/UniversalMediaServer/commit/54d746d7ddf387ad90bbc32b68fbf9c4b75eaef8

[Nadahar]

@Sami32 I don't think you properly understand the relationships between the commits in this case, and it's no wonder since this is the type of "messed" history full of merges in all different directions that I'm often saying is very hard to figure out.

The two commits you compared belongs to different branches, so even though it works with one of them and not the other it doesn't necessarily have to do with any of them. These two branches have a lot of different commits, and the two isn't "brought together" until the next merge between them. The difference in behaviour could come from any commit belonging to either branch all the way back to the fork point.

If you want to find out which commit that broke it, you have to stick to testing commits one one branch and then find the one where the bug appears.

I have a suspicion of what can be causing this though. 5.0.0 introduced something called "device configuration" where the "primary configuration" is combined with the renderer configuration making a "composite" configuration. When a user changes the shared folders, that change is made in the "primary configuration". I doubt there are any updates made to the composite configurations when the primary configuration is changed. Thus, all renderers that already existed at the time of the change, will use the "old" shared folders.

It's pretty easy to test if this is the problem: Make sure the renderer in question is disconnected so that UMS can't see it, change the shared folders, click the "restart" button and then connect the renderer. If that renderer sees the "updated" shared folders, this is the cause. There's no easy fix for it as I see it though, it's what I'd call a "error by design".

[Nadahar]

@Sami32 If you look at GitHub's network graph you can get an idea of what I mean. Unfortunately I can't find a way to search for a commit in there, so you'd have to hold arrow left for a good while to go back to 2014 and see the commits in question.

TortoiseGit does this much better though, just open she "show log" in TortoiseGit and search for the SHA-1. It will then filter on that commit, which is not what you want. When the commit is found, click it once so that it's selected, and the click the X in the filter field above. That will show all commits again, but you are now at the point in time where that commit happened. TortoiseGit shows the graph vertically, on the left side of the screen. Each vertical line represents one branch, and you can see by the "dots" which branch which commit is on.

If you want it really ugly and hard to read, you can also use git log --graph.

[Sami32]

@Nadahar Thanks, but Github graph is too slow on my computer, not usable.
Instead i used the traditional browsing history:
https://github.com/UniversalMediaServer/UniversalMediaServer/commits/master?after=556f4ebc119065ef711d5404ece87ec17cb94ca9+2880

As since 3 years every developper tried and tested it already, i guess i better consider it as a part of UMS.

Thank you for sharing your knowledge, as no one here master the trees as you do :wink:

[Nadahar]

@Sami32 The problem is that the commit view you use doesn't show what you need. After branches are merged, there's no way to tell which commit has which parent / belongs to what branch in that view. They are simply listed chronologically by commit time, so it will be impossible to figure out the history using that.

You should use the TortoiseGit log view, that will run on your computer? It's much better than the GitHub view anyway IMO, and since this happened back in 2014 it doesn't really matter which branch you're on locally as they all share this history. You should try it 😉

I never "accepted" the "device configuration" solution, I think it creates more problems than it solves. But, it was before my time and I would probably have been overrun anyway when trying to point out the problems. This solution also creates a lot of thread-safety problems/bugs.

[Sami32]

@Nadahar It's nice to know, but i'm like a chicken having found a knife...that mean that i don't really know how to use the tree efficiently. So right now, it's not a job for me.

[Sami32]

@Nadahar Did you mean the 312 commits between them ?
I'm just trying to read the Git documentation on that matter so i'm sure if i do it correctly...

If that's really the case, do you have any advice how to proceed for the choice of the commits to be build and tested ?

[Nadahar]

@Sami32 If you use the graph either in TortoiseGit or git log --graph you can visually see the relationship between the commits (which is the next or previous commit of any given commit) by finding the next/previous commit on the same "line". To find the offending commit you can either start with a commit where the bug isn't present and work your way forwards on that "line" until the bug appears, or you can start with a commit where the bug is present and work your way backwards on its "line" until the bug disappears.

The problem is the merge commits (those commits where lines are combined). You don't have to try the merge commits themselves, as they don't (normally) change anything. If you work your way backwards and get to a merge commit, you have to try the last commit of both "incoming lines" (parent branches) and see where the bug is. If it's present in both, you should probably jump backwards to the next merge and do the same. If the bug is present only on one of them, then you should keep testing that "line"/branch. This is why I hate merges, it quickly becomes a lot of possible paths to follow.

If you work your way forward (from a commit where the bug is not present) and reach a merge commit, you can test the merge commit itself. If the merge commit has the bug, you know that the bug came from the other branch/line than the one you were on. You then have to stop going forward and start reversing on the other branch/line.

I don't know if you understood all of that, it's not so easy to explain given our language issues, but the logic of it all isn't that hard to understand one you realize a couple of things:

• Each non-merge commit only makes changes relative to the previous commit. A non-merge commit doesn't know anything about the repository in general, it only knows its parent and it makes changes to the code of the parent.
• A merge commit is a special kind of commit that ideally doesn't change the code. What it does is to combine the code of the branches/commits being merged. Git will do this according to certain rules automatically, but when Git can't figure out how to combine the two we have a "conflict". Conflicts must be resolved manually, and the only non-automatic change present in a merge commit is the conflict resolution (the result of the manual editing of the conflicting files). There's no easy way that I know of to see these manual changes, as they are combined with the "automatic" changes, but normally one doesn't add code or change functionality in a conflict resolution, one only tries to combine the two versions of the code. That's why I say that a merge commit "normally" won't change code, because there's no limit to what can be changed during conflict resolution so theoretically a lof of code could be added, deleted or changed, but I don't think most people will do that. Bugs can arise in merge commits though, as the conflict resolution can sometimes be difficult and the person doing it can misunderstand or fail to think of how one or both of the incoming "versions" of the code is working. I doubt this bug is a result of a merge commit though, so I think you can ignore any changes in merge commits for now.

[Sami32]

@Nadahar I checked 2 days ago the Git documentation, still need to go deeper if i want a more fine tuned filtering, but when i saw all the merges commit and all the commits that have been merge with conflicts and don't even build, some if i escape the tests, i just became sick.
I don't even know how you have managed to resolve the 7.0.0 branch !!! God bless you :wink:

So, i guess i'll take rest on that for now, and think about how to make checkmate in less of 10 moves ;-)

EDIT: I just begin to understand all your interest/motivation to have a clean tree...

[Nadahar]

@Sami32 Good, I was feeling a little bit "alone" in that regard 😄

[Sami32]

@Nadahar OK, i think i found a nice command line Git formula that feed my need.

But i'm loose, as when i tried the parent of what i said that was the culprit commit, and you said not, i didn't reproduced the bug: b2e9a11

So did i understood incorrectly, or had you told me b.uls..it ?

[Nadahar]

@Sami32 I'm not sure I understand, or: I'm sure I don't understand you now. b2e9a114f6aa6559295c72e6a9d93cc0eaf914b1 is the parent of f478c88a6033edbb2f66a735a766ac53e89e85f0, that we agree on. But if you say that the bug is there with f478c88a6033edbb2f66a735a766ac53e89e85f0 but not with b2e9a114f6aa6559295c72e6a9d93cc0eaf914b1 I don't understand anything, as I can't see any changes in f478c88a6033edbb2f66a735a766ac53e89e85f0 that could impact shared folders.

[Sami32]

@nadahar OK, i think i get senile...
I really don't know what happened, but now i pointed the bug to this commit:
82b930cf5eae6d3142aad7cefcee886f3f07d0a7

And worst of it, i don't understand how it could give that issue ??? isUseCache() related ?

As Git tree use is totally new for me, your help/advices will be greatly appreciated !

[Nadahar]

@Sami32 82b930cf5eae6d3142aad7cefcee886f3f07d0a7 only changes the default value for isUseCache(). I think it's strange if this is the culprit, but you can always test by turning the cache on and off (overriding the default) and see if that affects the bug.

[Nadahar]

@Sami32 By the way, it must take an enormous amount of time to test commits the way you do. Let me remind you that if you used Eclipse you could just checkout the commit, press F5 to refresh the files in Eclipse and then press F11 to compile and run UMS for that commit without having to wait for Maven.

[Sami32]

@nadahar I tried already, and i find this too strange. Something need to happend that i'm not able to understand, yet.

So, as for you it take 30s, could you try it and confirm it ? Thanks.
His parent is fine.

[Nadahar]

@Sami32 I can't check out anything right now, I'm still working on #1267 and have lots of uncommited files.

[Sami32]

@nadahar Never mind, this issue can wait a little more your lights, as i don't think some days more will make any differences :wink:

[Sami32]

@Nadahar So can you confirm that it ppear at that commit ?

[Nadahar]

@Sami32 Which commit? If you're referring to 82b930cf5eae6d3142aad7cefcee886f3f07d0a7 there's no point in testing, all it does it changing the default for using the database from off to on. Which commit do you consider to be the parent?

[Sami32]

@Nadahar I consider nothing. I just asked to test the commit before (9fa0bf7d13d92d625e0b22d11d4dcaa5859472c4) and see this bug is not there.
And test https://github.com/UniversalMediaServer/UniversalMediaServer/commit/82b930cf5eae6d3142aad7cefcee886f3f07d0a7 and see that this bug appear.

EDIT: I just need a confirmation of what i tested, because i found this strange.

[Nadahar]

@Sami32 There's no need to test, the bug isn't in 82b930cf5eae6d3142aad7cefcee886f3f07d0a7. Set use_cache = true in UMS.conf and test 9fa0bf7d13d92d625e0b22d11d4dcaa5859472c4 and you will see the bug there as well.

[Sami32]

Are you kidding ? How do you want test this bug without cache enable ? the scan will not work without that...
Forget about, we live since 3 year with it without complain so it's fine.

[Nadahar]

Don't close things that are unresolved.

I don't know how you test this, but there's no need to do a scan to test it. You can simply use a renderer to browse folders, which is what I would do. I use Kodi for all such testing, it's much quicker that to do a scan.

That said, I never said that you should disable the cache, I said that you should enable it. If you look at 82b930cf5eae6d3142aad7cefcee886f3f07d0a7 you will see that all it does is to change the default for use_cache.

[Nadahar]

@Sami32 I think I've figured why I've been wrong about this issue from the beginning. I've never actually tried to use scan after modifying the shared folders, because I've had the same issue all along when using Kodi. I've assumed that this had the same cause. That turned out to be wrong.

It seems that the reason that I have to restart UMS to register changes in shared folders is a bug in Kodi. I don't know quite how it works, as it doesn't help if I restart Kodi, but it probably has some caching that causes this. When using Foobar2000 this bug "doesn't exist" even with latest master, so I've been talking about something else from the beginning.

I now understand why you thought it was stupid of me to assume that this could be tested with the cache turned off. I've tested both 82b930cf5eae6d3142aad7cefcee886f3f07d0a7 and 9fa0bf7d13d92d625e0b22d11d4dcaa5859472c4 and experience the bug in both commits. I went further to see how far back this went, and it turns out that UMS 1.1.1 also has the same bug. I then switched to PMS and worked my way back to PMS 1.5.0. The bug exists there as well.

I couldn't go further than PMS 1.5.0 because the previous versions have a completely different folder structure, and I'd have to reconfigure the project in Eclipse to test those. I'm pretty sure that the bug has been there from the start though.

[Sami32]

@Nadahar I saw many times that you only use Eclipse and Kodi for testing, that's said you're not the only one as it's more easy, fast for you, but it's also why many issues cannot be reproduced. I'm a too basic for using other tools that the "fundamental"/root ones.

Thank for finally having really tested it !
No, "stupid" was not the word that came to my mind, but i'll lie if i don't say that many "bird's name" came to my thoughts...

As i said long before in that thread 1.0.3 seem to be the one where it appeared, but i was not able to build it, and never tried since then, though i think that i keeped the original code somewhere.

I'm double surprised. The fact that you cannot reproduce it, make me think that something is linked to the start configuration file. And the fact that this time you finally fixed it :P
Whatever, i'm happy to see it fixed, as it should be useful in general, and also because we didn't loose our time for nothing.

Right now, that's not easy for me to tell this to you, but... good job :tongue: