Kodi Community Forum

ronie Wrote:nice find!
this indeed works great :-)

besides not needing the refresh property anymore, would this also fix the issue some users are having with the slideshow not refreshing after all images are downloaded?

Maybe container refresh can do the trick?
Tried this with extrafanart in DialogVideoInfo and that seems to work.

Quote:oh btw , i've updated the skin integration info on the first post, you may want to make the same changes in the readme file.

And if you want to keep the wiki page up-to-date as well (we are trying to get more and more add-on to do that).
I can help you to get the initial things setup up there.

ronie Wrote:besides not needing the refresh property anymore, would this also fix the issue some users are having with the slideshow not refreshing after all images are downloaded?

That was what I was trying to fix to start with, and it does seem to address that (I never could get my setup to refresh the old way).

Quote:if not strictly needed (as per my comment above), i'd say just hard-code it to 1 second. we don't want users have to dig through skin xml files to figure out what fadetime their skin uses. imo, the addon sets the standard and skins should adopt to it.

It is needed. If you don't pause, the skin doesn't seem to notice the directory change. I agree that we don't want the users to hunt through the skin. Since your original example used two seconds, I think I'll hard code it to 2 seconds. If the pause is shorter than the fade time, the transition looks like crap.

Quote:i'm perfectly fine if you want to maintain the addon from this point on.
if so, just submit a pull request on the addon mailing list as soon as you think things are stable enough for inclusion in the addon repo.

I certainly appreciate the vote of confidence and will be happy to do that.

Quote:oh btw , i've updated the skin integration info on the first post, you may want to make the same changes in the readme file.

Will do.

Martijn Wrote:And if you want to keep the wiki page up-to-date as well (we are trying to get more and more add-on to do that).
I can help you to get the initial things setup up there.

I can do that and would appreciate the help getting the initial setup done. I assume we can use the README file as the basis?

v1.2.0
- added ability to use local or remote images
- added priority image control to use local first, remote first, or both
- added option to restrict downloads to 16:9 images
- added option to have slideshow refresh after every image download or after x seconds
- added option for override folder that will be showed instead of artists images
- updated logic to refresh images after all are downloaded
- fixed potential script crash if remote sites unavailable
- experimental support for limiting size of cache folder

This should be showing up for folks in the next few days or so.

The last thing I added before the pull request was experimental support for limiting the size of the cache. I say experimental because while it works without a hitch on OSX (and probably Linux given they are at their very core Unix variants), on Windows I ran into some weird problems I had to error catch around. Specifically Windows (at least on my machine) sometimes only mostly deletes directories (it's like being mostly dead for you Princess Bride fans). What is left there still shows up in the directory listing but is inaccessible. After adding the error catching, I ran this for about five hours on my Windows machine without any issues, but I still decided to mark the feature experimental now.

The cache manager only attempts to limit the cache in the addon data directory. The smallest size limit you can set is 256mb and the largest is 4gb (obviously if you don't turn on cache management, you are limited only by your disk space). I was trying to balance disk use with API use for the remote sites, and I think even 256mb still strikes that balance. If you can't spare 256mb on your drive, you really need to think about getting a new drive. :p

The cache limit you set is sort of an ideal rather than an absolute. There are two use cases where your cache will get larger than the maximum.

1- The cache manager will not delete the only folder in the cache, so if you have an artist that has lots of artwork (I mean *lots*) and that is the only artist in the cache, the cache could be larger than the max set. If you find an artist with more than 256mb of downloaded images, please let us know. I'd like to see that one.

2- The cache manager trims the cache after downloading the images for the currently playing artist. So if you are close to the max, the current artist could push you over the top for a brief moment. Once all the current images are downloaded the cache will drop below the max size.

If you decide to use both local and remote images, you are own your own for space management. There is no way I'm going to start mucking around in a directory that has some script managed content and some user managed content.

Baring bugs or new feature requests, the only thing I'm working on is to get the script to take an artist as an argument so that other plugins can use this plugin to display music slideshows (i.e. the new Squeezebox plugin). We're making baby steps on that front.

pkscuot Wrote:I can do that and would appreciate the help getting the initial setup done. I assume we can use the README file as the basis?

Ofcourse. So if you already put everything in the readme i'll make a nice wiki for you to start with

Martijn Wrote:And if you want to keep the wiki page up-to-date as well (we are trying to get more and more add-on to do that).
I can help you to get the initial things setup up there.

I found the wiki page, created an account, and added the readme information for version 1.2. I also noted that 1.1.5 is the last version for Dharma and that the information on the page was for version 1.2.

Quote:Unfortunately the refresh after each download doesn't work all that well because it changes images instantly when downloaded. Can you put a minimum refresh threshold?

pkscuot Wrote:OK, that option is in there now. Re-download and give it a try. The option to limit the cache size is going to take a bit longer.

This works a lot better now. There are some minor problems left that I don't know if they're fixable.

The fade from picture to black and black to picture when a refresh happens becomes a bit annoying after a while. This doesn't happen on the normal refreshes since the images fade into other images and not black.

Also I've seen some overlaps of the 2 refresh methods. I've put the minimum time at 5 secs and some times a fade to other image and fade to black happens at the same time.

Last one annoying thing is that at the first 4-5 refreshes I usually get the same image after refresh so it goes Image#1 -> fade to black -> fade to Image #1 -> fade to black -> fade to Image#1

As I said these are all minor problems and I don't know if they're fixable

Looking good in my favorite new skin Xeebo.

Vrok Wrote:The fade from picture to black and black to picture when a refresh happens becomes a bit annoying after a while. This doesn't happen on the normal refreshes since the images fade into other images and not black.

The fade to black is the lesser of two evils. Without the fade to black you get a very jarring instant switch transition which, trust me, looks even worse.

Quote:Also I've seen some overlaps of the 2 refresh methods. I've put the minimum time at 5 secs and some times a fade to other image and fade to black happens at the same time.

I would set the minimum time to something longer than the time a slide is suppose to display. The default is 20 seconds and seems to minimize the annoyance (with the trade off being that first image stays there longer).

Quote:Last one annoying thing is that at the first 4-5 refreshes I usually get the same image after refresh so it goes Image#1 -> fade to black -> fade to Image #1 -> fade to black -> fade to Image#1

Yea, there's nothing to be done about that. The skin randomizes the slideshow. During the first download there is 1 image, so that's what is shown. If you only download one more image before the next refresh, there are 2 images, so there is a 50% chance you'll get the same image. With three it drops to 33%, etc. So the longer the minimum refresh is, the more likely you are to have more images, thus reducing the chance you'll refresh into the same image again.

Massive thank you to pkskout...this script is finally running with 100% slickness even with my crappy connection. All the changes to the refresh mechanisms are working a treat for me.

A couple of questions...

Quote:both will check for local images first. if they exist the downloaded images will be placed in the same directory as the local images. if not remote images will be stored in normal cache dir. if nothing found will use fallback slideshow.

Would it not be possible to always download to the local music artist/extrafanart folders? In other words to create such a folder if it doesn't already exist. That way one could do away with the cache folder in appdata altogether and have a nice collection of images stored locally alongside each artist's mp3 files.

Also, is the script now setup to use all available previously-downloaded images evn if the XBMC box is offline? If not, would this be possible.

Thanks again to you and Ronie for this amazing XBMC feature

NisseDILLIGAF Wrote:I get both artist name and song name in the title and it manage to download the correct artist..


Here's my default.py file

Anyone can help with a reup of this file?

Because I can't seem to get the artistslideshow to work with my radio station (977music using shoutcast)
I've also tried to change change.name and self.name as suggested at page 19:

NisseDILLIGAF Wrote:Thanx!!

I had to change default.py in 3 places using this...

Code:

currentname = xbmc.Player().getMusicInfoTag().getArtist()
if len(currentname) == 0:
    currentname = xbmc.Player().getMusicInfoTag().getTitle()

and this...

Code:

self.NAME = xbmc.Player().getMusicInfoTag().getArtist()
if len(self.NAME) == 0:
    self.NAME = xbmc.Player().getMusicInfoTag().getTitle()

Now it downloads both when I play MP3 and Radio

kiboy6 Wrote:Would it not be possible to always download to the local music artist/extrafanart folders? In other words to create such a folder if it doesn't already exist. That way one could do away with the cache folder in appdata altogether and have a nice collection of images stored locally alongside each artist's mp3 files.

It's certainly possible. The balancing act is to have a reasonable number of options and not have the settings require a Ph.D. to decipher. I think we're nearing the edge in terms of the complexity of the settings. I already get the chills by writing stuff into a user created directory. I'm really not liking the idea of creating directories in that structure as well.

You can do this manually now by preferences local artwork and then going through the cache folder periodically to move stuff you want to move. That's actually what I do right now (mostly in cases where I'm getting a weird mix of images in the downloads).

Quote:Also, is the script now setup to use all available previously-downloaded images evn if the XBMC box is offline? If not, would this be possible.

I assume based on your question that your local image folder is on an SMB share or something like that. To be honest, I didn't do any testing of SMB shares for local artwork mostly because, in my setup at least, trying to have a slideshow on the home screen point to an SMB share didn't work.

I did just look through the code. The logic for the local images tries to do a file list of the directory specified. If it gets any OSError it assumes there are no images. So, at least in theory, if your images are on a share that isn't mounted, the local image lookup would fail and it would fallback to remote images.

Linde Wrote:Anyone can help with a reup of this file?

Because I can't seem to get the artistslideshow to work with my radio station (977music using shoutcast)
I've also tried to change change.name and self.name as suggested at page 19:

With the release of 1.2 that file wouldn't help you anymore (even if someone has it). The code for 1.2 has a bunch of changes. What problem are you trying to solve?

pkscuot Wrote:With the release of 1.2 that file wouldn't help you anymore (even if someone has it). The code for 1.2 has a bunch of changes. What problem are you trying to solve?

I think he is talking about the changes I made to get the code to work with radio stations that type the artist info in the Title tag instead of the Artist tag...

I haven't looked at new code yet, but was thinking about forking it on git and try some changes to get it to work again...

Don't have the time tonight.. maybe tomorrow..
I think it shouldn't be that hard to get it to work with radio...

NisseDILLIGAF Wrote:I think he is talking about the changes I made to get the code to work with radio stations that type the artist info in the Title tag instead of the Artist tag...

I haven't looked at new code yet, but was thinking about forking it on git and try some changes to get it to work again...

Good enough. Once you get it working I'd be happy to merge it back in so that functionality can be included in the next release.