Bug #168
closedxbmc.settings wrong path
0%
Description
I use this method to call my scripts settings:
xbmc.Settings(path="Q:\scripts\XOT-Uzg.v3\").openSettings()
It then shows a dialog without any text and this error is logged in the XBMC logfile:
ERROR: Unable to load: special://home/plugins/Q:/scripts/XOT-Uzg.v3/resources/settings.xml, Line 0
I can use the settings by calling:
xbmc.Settings(path="Q:\scripts\XOT-Uzg.v3\").getSetting(id)
Am I doing something wrong? If I use the context menu on my script, it does work.
Updated by arnova almost 13 years ago
Did you also test this on mainline xbmc? And if so: does it have the same problem?
Updated by basrieter almost 13 years ago
Yes, it works in the main XBMC versions. Just not on XBMC4Xbox.
I also created a topic on this, see this thread: http://www.xbmc4xbox.org/forum/viewtopic.php?f=15&t=2436
Updated by arnova almost 13 years ago
This bug is already quite old isn't it? I recall seeing this for ages....
Updated by basrieter almost 13 years ago
Replying to [comment:4 arnova]:
This bug is already quite old isn't it? I recall seeing this for ages....
I never really used the Add-on settings before, so it could be that it was there before. I just noticed it recently while 'pimping' my Add-on.
Updated by arnova almost 13 years ago
Bas, can you provide a simple code example/script to trigger the issue (I'm not a king a coding Python), I'll have a look at it then.
Updated by basrieter almost 13 years ago
Sure, download XOT-Uzg.v3 from www.rieter.net. Run it, select a channel at the bottom of the screen and then use the context menu and select the Addon Settings button.
Updated by arnova almost 13 years ago
- Status changed from In Progress to Closed
- Resolution set to fixed
Fixed in r30909.
Cheers!
Updated by arnova almost 13 years ago
Btw. the "empty dialog" issue has been resolved in r30910
Updated by buzz almost 12 years ago
- Status changed from Closed to Feedback
- Resolution deleted (
fixed)
I tracked down a problem with opensettings not working to this fix.
the old code
would run the first block if
a) there isn't a match
b) a match was found at something other than position 0
the fix in r30909 changes the logic to
would run the first block if
a) there is a match at position 0
This breaks opening settings with path set to plugin://video/something for example as then it should be running the second block of code, as it is already a URL.
I'm going to commit this, but welcome comments from Arnova (I know moved on from project, but as it was his commit). This might re-break the issue in this bug, but that needs to be fixed another way perhaps - maybe by calling with a special path.
Index: C:/Repos/xbmc/trunk-plain/xbmc/lib/libPython/xbmcmodule/PythonSettings.cpp
===================================================================
--- C:/Repos/xbmc/trunk-plain/xbmc/lib/libPython/xbmcmodule/PythonSettings.cpp (revision 31098)
+++ C:/Repos/xbmc/trunk-plain/xbmc/lib/libPython/xbmcmodule/PythonSettings.cpp (working copy)
@@ -170,7 +170,7 @@
{
bool ok;
CStdString path = self->pSettings->getPath();
- if (path.Find("special://home/plugins/") == 0)
+ if (path.Find("special://home/plugins/") == -1)
{
CURL url(path);
Py_BEGIN_ALLOW_THREADS
Updated by buzz almost 12 years ago
I might have misunderstood this slightly, in what the first portion of code works, but it seems we dont want to use that code even if the path is a url it seems.
Updated by buzz almost 12 years ago
I think I will revert to the way it was before nukas patch which doesn't seem needed ( no iff. call settings with path)
Updated by buzz almost 12 years ago
changed in r31103 - XOT-Uzg.v3 and plugin settings seem to work now. Original poster: do let me know how it works for you.
Updated by basrieter almost 12 years ago
Ok, I will let you know after I did a build and updated my Xbox. It could take some time.
Updated by arnova almost 12 years ago
The commit message for r30909 is somewhat confusing but the fix itself is ok (meaning the Find() was used incorrectly). Not sure about the actual logic. I never understood why we special case the special://.... path from other URLs but it at least fixed the issue back then. This means that the fix in r31103 might as well be correct :-)
Updated by buzz almost 12 years ago
- Status changed from Feedback to Closed
- Resolution set to fixed