2014-02-18, 03:25
(2014-02-18, 02:26)cg110 Wrote: While I'm comfortable that the code does work for the simple cases it's not fully tested, so be aware of that before pushing it into your elec/rpi build.
Certainly I'm wondering if the list manipulations will work correctly (eg writers) as the transaction starts by deleting everything, and then adds the missing elements.
Yes, hopefully I've made it clear that it's not for everyone and taking a backup before testing would be a good idea. Additional testing might help reveal a few more "gotchas" that can be nailed early on before this gets wider exposure.
(2014-02-18, 02:26)cg110 Wrote: Also your post made me spot a missing short cut. If the list of updatedDetails is empty then don't transact nothing to the sql db. This is possible in the case that it's a refresh that doesn't change anything. You did hint in your testing, that you had to force a change in the rating/votes count for it to do anything.
Anyway I've done an update that makes the Update code just return if there ends up being an empty updatedDetails set.
Yes, I saw it performing a start/commit transaction even if nothing is being updated, didn't think it was worth mentioning but glad you spotted it. Your update made it into the test build and is working as expected.
I've tested setting/clearing artwork and that seems to be working fine:
Setting a clearart artwork on a movie with three existing artwork types (logo, fanart and poster):
Code:
01:06:47 2487.320801 T:2836395088 DEBUG: JSONRPC: Incoming request: {"jsonrpc": "2.0", "params": {"art": {"clearart": "http://assets.fanart.tv/fanart/movies/19908/movieart/zombieland-4fd8c70fd673c.png"}, "movieid": 744}, "method": "VideoLibrary.SetMovieDetails", "id": "libSetDetails"}
01:06:47 2487.439697 T:2836395088 DEBUG: Mysql Start transaction
01:06:47 2487.444092 T:2836395088 DEBUG: Mysql execute: INSERT INTO art(media_id, media_type, type, url) VALUES (744, 'movie', 'clearart', 'http://assets.fanart.tv/fanart/movies/19908/movieart/zombieland-4fd8c70fd673c.png')
01:06:47 2487.483643 T:2836395088 DEBUG: Mysql execute: UPDATE art SET url='http://assets.fanart.tv/fanart/movies/19908/hdmovielogo/zombieland-5145e97ed73a4.png' where art_id=25818
01:06:47 2487.975586 T:2836395088 DEBUG: Mysql execute: UPDATE art SET url='nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Zombieland (2009)[BDRip]-fanart.jpg' where art_id=25807
01:06:47 2487.997070 T:2836395088 DEBUG: Mysql execute: UPDATE art SET url='nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Zombieland (2009)[BDRip]-poster.jpg' where art_id=25808
01:06:47 2488.027344 T:2836395088 DEBUG: Mysql commit transaction
01:06:47 2488.036621 T:2836395088 INFO: JSONRPC Server: Disconnection detected
However there is an oddity when clearing/removing an artwork item - the delete doesn't appear to be in the same transaction as the updates:
Code:
01:03:33 2293.269775 T:2836395088 DEBUG: JSONRPC: Incoming request: {"jsonrpc": "2.0", "params": {"art": {"clearart": null}, "movieid": 744}, "method": "VideoLibrary.SetMovieDetails", "id": "libSetDetails"}
01:03:33 2293.385742 T:2836395088 DEBUG: Mysql Start transaction
01:03:33 2293.392334 T:2836395088 DEBUG: Mysql execute: UPDATE art SET url='http://assets.fanart.tv/fanart/movies/19908/hdmovielogo/zombieland-5145e97ed73a4.png' where art_id=25818
01:03:33 2293.957520 T:2836395088 DEBUG: Mysql execute: UPDATE art SET url='nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Zombieland (2009)[BDRip]-fanart.jpg' where art_id=25807
01:03:33 2294.042725 T:2836395088 DEBUG: Mysql execute: UPDATE art SET url='nfs://192.168.0.3/mnt/share/media/Video/MoviesHD/Zombieland (2009)[BDRip]-poster.jpg' where art_id=25808
01:03:34 2294.231934 T:2836395088 DEBUG: Mysql commit transaction
01:03:34 2294.236328 T:2836395088 DEBUG: Mysql execute: DELETE FROM art WHERE media_id=744 AND media_type='movie' AND type='clearart'
01:03:34 2294.501709 T:2836395088 INFO: JSONRPC Server: Disconnection detected
Given the above, I must ask if it is necessary to update all the other list items that are not being referenced in the JSON call. I haven't looked at the code, but maybe the list processing isn't so easy to optimise and if that's the case fortunately the overhead doesn't appear to be particularly significant (although that could change if there were maybe a hundred or so list items, ie. cast members).