UMS 6.0.0 broken on NixOS #829
Comments
|
And this is introduces since the change in PMS.init() , https://github.com/UniversalMediaServer/UniversalMediaServer/blob/master/src/main/java/net/pms/PMS.java#L418 |
|
@thall I don't quite follow your logic. The path calculation has been like it is since 5.0.0. The new call in 6.0.0 just initializes the database earlier - I can't quite see how 6.0.0 could have changed the location itself. Are you sure this hasn't failed also in earlier versions, but that you haven't noticed since the failure hasn't aborted initialization? What I find strange is why the database is placed relative to the "current dir" for non Windows installations. @skeptical Can you shed some light on that? |
|
@Nadahar , It have been working for both 5.3 and 5.4. Yes i also find it strange it worked in earlier versions. See trace log below. It seems that the database isn't initialize at all. So that would explain why it worked before. But the path calculation i also find strange.
|
|
@thall |
|
@Nadahar , i changed it, everything worked.
But the database doesn't exists.
Seems like the database isn't used or an exception is ignored. |
|
I'm pretty sure the exception is ignored and that's what's actually different here. We've reorganized the database initialization because the database is used for more things and initializing it "on demand" was no longer practical. The result is that a hidden bug is revealed. While it would be simple to just ignore the Exception, that's not a solution as I see it. The problem here is the path used. I'd really like if @skeptical could shed some light on this solution. |
|
Alright. Nice then this bug has revealed it self. I agree that wouldn't be an solution. Will be interesting to hear what @skeptical says. |
|
@skeptical Do you know why the database file is placed relative to the binary and not in the profile folder on Linux and OS X? |
|
@thall In my case the database is relative to my program folder too, but I'm using a 'standalone' installation (i.e. I just untar UMS to a local user-accessible path), and so it naturally has write privileges there. I've never really tried a system install in linux (it doesn't seem necessary to me). DEBUG 2016-02-10 14:18:46.562 [main] Using database URL: jdbc:h2:/f/git/ums/database/medias
INFO 2016-02-10 14:18:46.562 [main] Using database located at: /f/git/ums/database
DEBUG 2016-02-10 14:18:47.103 [main] Database file count: 705 |
|
@skeptical Still it would make sense if it worked for people that did install it "normally", that is without write permission to binaries. That, and the fact that it will cripple multiple profiles as they will share the database. My question is if there's any reason to keep it like that, or if we should just move the database to the profile folder where it naturally belongs and write permission can be expected. |
|
@Nadahar I've never looked at the linux db logic as such, so I don't know if there was some special reason or whether it's just an oversight or something. I think you've looked into this stuff much deeper than me. Just for the sake of discussion, per the wiki the "normal" way to do a linux install of UMS is a simple untar. There are a couple of over-thought/wrought user-contrived how-tos for system installation (and pms used to have an unofficial deb package for a while) but java is supposed to be (ideally, in theory anyway :-) 'unpack and run' as I think we discussed once before. But I agree in the real world it's best to support system installs properly, since many will choose to go that route. |
|
Is this something that will be prioritized in any foreseeable future? |
|
Please let me know if this is resolved in 6.2.2 |
|
It works now, thanks :) Made an pull request to NixOS/nixpkgs#14555 |
|
Thanks for confirming, and for that PR :) |
Since 6.0.0 UMS is broken, since it tries to initialize database in a read-only path.
The problem is https://github.com/UniversalMediaServer/UniversalMediaServer/blob/master/src/main/java/net/pms/dlna/DLNAMediaDatabase.java#L90 , which returns a new file relative to where it executes if it not windows. It should return a file which is relative to a user directory.
The text was updated successfully, but these errors were encountered: