Bugzilla – Bug 527
irmap preference should not use absolute path
Last modified: 2008-12-18 11:55:42 UTC
The irmap preference is stored as an absolute path: 00:00:00:00:00:00-irmap = /export/SlimServer_v2004-09-01/IR/custom.map This means any custom mappings for your players break on a software upgrade. The annoyance factor of this increases if you have a lot of players and even more if you are a developer! You can work around this with symbolic links but it would be kinder to just store the map name and have the server search all the IR directories for it. 00:00:00:00:00:00-irmap = custom.map
Created attachment 116 [details] seems to work This seems to clean up the prefs to jsut the file name. On loading, it will try the full list of dirs, reading in the first valid file it finds.
Created attachment 117 [details] fix lookup function that last one needed a bit of a tweak to get the lookupFunction to work.
Created attachment 119 [details] keeps it backward compatible this will allow existing settings to work without a change. going into settings will take the new filename only value.
*** Bug 315 has been marked as a duplicate of this bug. ***
How about we make this a change for 6.0? I dont see any reason for the pref to written as absolute. the patch works, and we can use the 'update scripts' to convert it if we want to ensure its changed while starting up.
oh, and the dupe bug that joined this, means that ir AND map files will be made a file pref, instead of absolute path/file.
Created attachment 259 [details] handle both map and ir files This reads both absolute and file prefs. if the user goes into settings to changes anything, we'll now write only the file name to the pref
dan, what do you think of this? I've been playign around tonight, and since I have two players in the same room, this bug is driving me bonkers with 5 copies of svn. I have to reset the remote settings every time. it seems silly to me that so many other prefs are without the absolute path. I will likely have to rework this yet again for current rev, but I can't be bothered unless there is a chance it will actually get committed this time :)
Created attachment 346 [details] updated to fit with 6.0, but holding off until after release This just removes one hunk of the previous patch that would fail. The old CVS id is irrelelvant now anyway.
Dan, can we give KDF the go ahead on this patch?
Yes, go for it.
committed fix to trunk at change 3352
This bug was marked resolved in Slimserver 6.1, which is several versions ago. If you're still seeing this bug, please re-open it. Thanks!
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.