2013-11-10, 05:38
@Montellese: It's been a bit of a saga and this post may be a little long winded, but I hope you can bear with me...
I've become aware of at least two addons that are "mangling" urls in the media library by creating urls with a mixture of forward and backwards slashes, for instance (and I think this was caused by Artwork Downloader):
Note the banner, clearart, clearlogo, discart and landscape urls with the Unix-style forward slash between the last directory and artwork filename, even though the urls are clearly for a Windows system.
Although not right, these mangled urls don't seem to be a problem for the GUI - despite the media library referencing a "mangled" url, the GUI will locate the artwork successfully and then cache it without any problem, creating a similarly mangled url entry in the texture database.
Now comes the problem: when requesting artwork with mangled urls via the webserver, it appears that the webserver is correcting the forward/backward slashes in the url and will create an entry in the texture database that is not mangled. Consequently, the GUI cannot find this cached item (as the GUI is looking for the mangled version of the url) and will proceed to create another cache entry, this time using the mangled url as it appears in the media library.
Is there any way that the webserver can be made to stop correcting mangled filenames on-the-fly whenever it creates (or possibly even looks up) a row in the texture cache? This no-touch behaviour would then be consistent with the GUI caching behaviour. Alternatively I suppose the GUI could correct urls on the fly, but I'm guessing that's going to cause more overhead and is not ideal.
Here's a worked example:
Note how the poster has a Windows-style backslash between the directory and filename.
Having removed all trace of the poster from Textures13.db, the poster is downloaded using JSON and the webserver:
JSON "Files.PrepareDownload" Request:
JSON "Files.PrepareDownload" Response:
Webserver (HTTP) Request:
All of the above urls contain the backward slash from the original url (ie. they're all "mangled" urls).
Having downloaded the item, the following row appears in Textures13.db:
Note the corrected forward slash between directory and filename - the url is no longer mangled!
Now browse to the same poster in the GUI, and the following row appears in Textures13.db:
Note how the url is as it appears in the media library, ie. mangled. The row inserted by the webserver (#31637) is ignored by the GUI.
The webserver caching behaviour should be consistent with the GUI, but it's not - any chance of a fix? I can't think how changing the webserver caching behaviour would break an existing addon or script, but I guess that's always something to be considered. Happy to help test...
Obviously it would be better if addons didn't create mangled urls, but ultimately the mangled urls they produce are not a problem for the GUI, only the webserver, and I can't see how it will be possible to prevent addons from continuing to create mangled urls, particularly those that insert rows directly into the database (JSON could perhaps fix urls as they are passed over?)
Many thanks for your consideration!
I've become aware of at least two addons that are "mangling" urls in the media library by creating urls with a mixture of forward and backwards slashes, for instance (and I think this was caused by Artwork Downloader):
Code:
"art": {
"banner": "image://I:\\Filmes\\007 Collection\\22.James.Bond.007.Quantum.of.Solace/banner.jpg/",
"clearart": "image://I:\\Filmes\\007 Collection\\22.James.Bond.007.Quantum.of.Solace/clearart.png/",
"clearlogo": "image://I:\\Filmes\\007 Collection\\22.James.Bond.007.Quantum.of.Solace/logo.png/",
"discart": "image://I:\\Filmes\\007 Collection\\22.James.Bond.007.Quantum.of.Solace/disc.png/",
"fanart": "image://http://d3gtl9l2a4fn1j.cloudfront.net/t/p/original/hfZVY8lMiE7HH1cDc2qzSFF6Kbt.jpg/",
"landscape": "image://I:\\Filmes\\007 Collection\\22.James.Bond.007.Quantum.of.Solace/landscape.jpg/",
"poster": "image://http://d3gtl9l2a4fn1j.cloudfront.net/t/p/original/fuQuV4JF6WflG22mgszXuAaaQVb.jpg/"
},
Note the banner, clearart, clearlogo, discart and landscape urls with the Unix-style forward slash between the last directory and artwork filename, even though the urls are clearly for a Windows system.
Although not right, these mangled urls don't seem to be a problem for the GUI - despite the media library referencing a "mangled" url, the GUI will locate the artwork successfully and then cache it without any problem, creating a similarly mangled url entry in the texture database.
Now comes the problem: when requesting artwork with mangled urls via the webserver, it appears that the webserver is correcting the forward/backward slashes in the url and will create an entry in the texture database that is not mangled. Consequently, the GUI cannot find this cached item (as the GUI is looking for the mangled version of the url) and will proceed to create another cache entry, this time using the mangled url as it appears in the media library.
Is there any way that the webserver can be made to stop correcting mangled filenames on-the-fly whenever it creates (or possibly even looks up) a row in the texture cache? This no-touch behaviour would then be consistent with the GUI caching behaviour. Alternatively I suppose the GUI could correct urls on the fly, but I'm guessing that's going to cause more overhead and is not ideal.
Here's a worked example:
Code:
[
{
"art": {
"clearart": "image://http://assets.fanart.tv/fanart/movies/19908/movieart/zombieland-4fd8c70fd673c.png/",
"clearlogo": "image://http://assets.fanart.tv/fanart/movies/19908/hdmovielogo/zombieland-5145e97ed73a4.png/",
"fanart": "image://nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Zombieland (2009)[BDRip]-fanart.jpg/",
"poster": "image://nfs://192.168.0.3/mnt/share/media/Video/MoviesHD\\Zombieland (2009)[BDRip]-poster.jpg/"
},
"file": "nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Zombieland (2009)[BDRip].mkv",
"label": "Zombieland",
"movieid": 667,
"title": "Zombieland"
}
]
Note how the poster has a Windows-style backslash between the directory and filename.
Having removed all trace of the poster from Textures13.db, the poster is downloaded using JSON and the webserver:
JSON "Files.PrepareDownload" Request:
Code:
{"jsonrpc": "2.0", "params": {"path": "image://nfs%3a%2f%2f192.168.0.3%2fmnt%2fshare%2fmedia%2fVideo%2fMoviesHD%5cZombieland%20(2009)%5bBDRip%5d-poster.jpg/"}, "method": "Files.PrepareDownload", "id": "preparedl"}
JSON "Files.PrepareDownload" Response:
Code:
{"id":"preparedl","jsonrpc":"2.0","result":{"details":{"path":"image/image%3a%2f%2fnfs%253a%252f%252f192.168.0.3%252fmnt%252fshare%252fmedia%252fVideo%252fMoviesHD%255cZombieland%2520(2009)%255bBDRip%255d-poster.jpg%2f"},"mode":"redirect","protocol":"http"}}
Webserver (HTTP) Request:
Code:
GET image/image%3a%2f%2fnfs%253a%252f%252f192.168.0.3%252fmnt%252fshare%252fmedia%252fVideo%252fMoviesHD%255cZombieland%2520(2009)%255bBDRip%255d-poster.jpg%2f
All of the above urls contain the backward slash from the original url (ie. they're all "mangled" urls).
Having downloaded the item, the following row appears in Textures13.db:
Code:
031637|9/9993f35a.jpg|2013-11-10 03:32:41|2013-11-10 03:32:41|nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Zombieland (2009)[BDRip]-poster.jpg
Note the corrected forward slash between directory and filename - the url is no longer mangled!
Now browse to the same poster in the GUI, and the following row appears in Textures13.db:
Code:
031638|b/ba80e1ed.jpg|2013-11-10 03:34:20|2013-11-10 03:34:20|nfs://192.168.0.3/mnt/share/media/Video/MoviesHD\Zombieland (2009)[BDRip]-poster.jpg
Note how the url is as it appears in the media library, ie. mangled. The row inserted by the webserver (#31637) is ignored by the GUI.
The webserver caching behaviour should be consistent with the GUI, but it's not - any chance of a fix? I can't think how changing the webserver caching behaviour would break an existing addon or script, but I guess that's always something to be considered. Happy to help test...
Obviously it would be better if addons didn't create mangled urls, but ultimately the mangled urls they produce are not a problem for the GUI, only the webserver, and I can't see how it will be possible to prevent addons from continuing to create mangled urls, particularly those that insert rows directly into the database (JSON could perhaps fix urls as they are passed over?)
Many thanks for your consideration!