I can now achieve a moveup or movedown with 15 steps that can be easily automated with AutoIt. Now that I have proved the concept, my next step will be to create those hotkey scripts.
My findings however have more to do with Serviio's behaviour in handling online sources, and I think identify some bugs/omissions/or redundant behaviour, so I will report them here for zips review, and attach the complete log as referenced below. (line numbers are available using notepad+ to edit the log)
First, I turned on debug for the online library and restarted Serviio
- Code:
<category name="org.serviio.library.online">
<priority value="DEBUG"/>
</category>
Observation 1: All my existing online feeds are identified as "not in cache yet, loading it", then reparsed, the contained fees added and then stored in the cache and the expiry set. It then finds "Found technical metadata for online item.. in the cache" which was retained for the feed so the parsing/caching is faster than for a new feed. This takes the log to line 1478 and required 2 minutes and 25 seconds from Serviio startup.
Serviio then confirms up to line 1511 that the 31 feeds are cached.
Then the log becomes weird...!!!
Observation 2: Every minute the 31 feeds are reconfirmed, this is repeated 17 times, then only the 18 video rss feeds, followed by the 2 video live streams are confirmed, then just the 18 video rss feeds, then the 18 plus the first rss feed, then various combinations of the above. I see no rhyme or reason for this variation or for the need to confirm all the feeds every 60 seconds.
I then proceeded to test some changes:
Test 1: simply changed (edit/add/save) the "Display name" of an existing feed (as available in beta3). The name changed in the TV menu immediately (exit and reopen OnlineFeeds), but no log entry is created for that action.
Test 2: I simply changed(edit/add/save) the "Source URL" of an existing feed (as available in beta3). The new log showed the old url deleted (line 4335) and the the new url added and reparsed.(lines 4364 to 4379)
Observation 3: The reparsing of the new url which had never been added to Serviio before and the addition and caching of its feeds was exactly the same as the parsing of the original url at Serviio startup. This new url had the same content as the old url and Serviio again "Found technical metadata for online item .. in the cache" for those items.
Then the log becomes weird again!
Observation 4: Following the addition of the new feed, the 31 feeds are again confirmed as cached one minute later, then in 36 seconds, then in 24, then in 16, then in 3, then 7 times within 1 second, then 10 seconds later 7 more times in 1 second, then 7 more times within 1 second, then 30 seconds later, then back to the 1 minute cycle, so we get a flurry of 26 confirmation cycles over 2 minutes... it just makes no sense. (lines 4384 thru 4824)
Test 3: Performed the 14 step "moveup" of an existing feed item within the console and then saved. The log shows the two swapped feeds being reparsed and the feeds added again the same as when these urls were parsed at startup (lines 7227 thru 7268) But again Serviio "Found technical metadata for online item .. in the cache" so it seems that the reordering of items still uses the retained information for the items in the reordered feeds, meaning reordering is no more intensive than a Serviio startup.
Observation 5: After these adds the confirmation that the feeds are in the cache goes bananas again with 20 some cycles being done over a minute or so. (lines 7288 thru 7707). Again makes no sense. The cycle then repeats every 60 seconds.