2014-08-14, 01:46
Weird.
Does it happen with Confluence? My guess is it's something about the skin you're using.
Does it happen with Confluence? My guess is it's something about the skin you're using.
2014-08-14, 02:44
You're right, I think it's skin related.The buttons show up in confluence. I've tried transparency and ace and the buttons don't show up in either. I'm running Gotham 13.1
2014-08-14, 02:48
ok bit busy today, will think about it. The skin files are in the addon folder if you want to poke around and work it out in the meantime!
2014-08-21, 15:22
Hi bossanova808,
I tried the XSqueeze Plugin on an ODROID-Hardware (ARM-Board) with XBMC 13.2.
After installation I had to manually correct some file links to tell the addon to use the squeezelite binary for the arm-architecture as it tries to start the x64 binary in the linux folder.
Once the plugin is startet it plays music and also shows the correct information about the stream but the interface gets kind of stuck. Pressing Buttons takes more than a second to respond or even does nothing. Changing volume or clicking on the close button also does nothing.
Maybe there is a known fix to this?
I tried the XSqueeze Plugin on an ODROID-Hardware (ARM-Board) with XBMC 13.2.
After installation I had to manually correct some file links to tell the addon to use the squeezelite binary for the arm-architecture as it tries to start the x64 binary in the linux folder.
Once the plugin is startet it plays music and also shows the correct information about the stream but the interface gets kind of stuck. Pressing Buttons takes more than a second to respond or even does nothing. Changing volume or clicking on the close button also does nothing.
Maybe there is a known fix to this?
2014-08-22, 01:03
Yeah the default is linux if it can't work out the architecture and I haven't really looked at non linux/mac/win so much.
So the Odroid runs with the arm hard float binary that comes with it - or did you pop another in?
The interface crawls a bit on the Pi too - I think it's basically not enough CPU as it's hell-for-leather polling the telnet socket (when it should be subscribe/listen).
I should really re-write that but I just don't have the time. How's your Python
?
So the Odroid runs with the arm hard float binary that comes with it - or did you pop another in?
The interface crawls a bit on the Pi too - I think it's basically not enough CPU as it's hell-for-leather polling the telnet socket (when it should be subscribe/listen).
I should really re-write that but I just don't have the time. How's your Python
?
2014-08-22, 10:33
Hi - thanks for your quick answer!
I tried both - the squeezelite binary from your latest release and the latest official binary. Same for squeezeslave. The raw CPU-power should be no problem as the Odroid is quite strong to render everything (XBMC menus, desktop, etc.) else very fast (especially compared to the pi). Maybe the problem is related to the telnet socket... do you have an idea how to get more information out of what actualliy blocks the interface? There is no entry in the xbmc-logs and python is version 2.7 - thanks in advance!
I tried both - the squeezelite binary from your latest release and the latest official binary. Same for squeezeslave. The raw CPU-power should be no problem as the Odroid is quite strong to render everything (XBMC menus, desktop, etc.) else very fast (especially compared to the pi). Maybe the problem is related to the telnet socket... do you have an idea how to get more information out of what actualliy blocks the interface? There is no entry in the xbmc-logs and python is version 2.7 - thanks in advance!
2014-08-22, 12:05
Well I've only heard of problems on the Pi so I wonder if it is something ARM related more than anything else, but I don't know really. I test it on Windows and OE clients, and occasionally Mac. None of those break a sweat at all, so I am not sure exactly what it is.
The design is stupid (based on the library available at the the time I wrote it). There's a thread that just polls the crap out of the telnet socket, and in a blocking manner as otherwise you get race conditions. Basically, you could try logging the traffic across that to see which bit is the issue...I'm presuming it's in there.
The design is stupid (based on the library available at the the time I wrote it). There's a thread that just polls the crap out of the telnet socket, and in a blocking manner as otherwise you get race conditions. Basically, you could try logging the traffic across that to see which bit is the issue...I'm presuming it's in there.
2014-08-26, 00:41
I'm having a weird problem with xsqueeze hanging on exit. It looks like it is waiting for Artist Slideshow to exit and never seeing that it does:
os: ubuntu 14.04 x64
xbmc: 13.2
artist slideshow: 1.6.8
xsqueeze: 1.1.1
Any ideas?
os: ubuntu 14.04 x64
xbmc: 13.2
artist slideshow: 1.6.8
xsqueeze: 1.1.1
Code:
18:31:33 T:140594617112320 DEBUG: [Artist Slideshow] ArtistSlideshow.50.AlbumName set to
18:31:33 T:140594617112320 DEBUG: [Artist Slideshow] ArtistSlideshow.50.AlbumThumb set to
18:31:33 T:140594617112320 DEBUG: [Artist Slideshow] unexpected error while setting property.
18:31:33 T:140594617112320 DEBUG: [Artist Slideshow] global name 'slideshow' is not defined
18:31:33 T:140594617112320 NOTICE: [Artist Slideshow] script stopped
18:31:33 T:140594617112320 INFO: CPythonInvoker(26, /home/xbmc/.xbmc/addons/script.artistslideshow/default.py): script successfully run
18:31:33 T:140594617112320 INFO: Python script stopped
18:31:33 T:140594617112320 DEBUG: Thread LanguageInvoker 140594617112320 terminating
18:31:33 T:140596459058944 DEBUG: ### XSqueeze-1.1.1 ### Still waiting for artistslideshow to stop
18:31:34 T:140598055720896 DEBUG: ------ Window Deinit (DialogKaiToast.xml) ------
18:31:34 T:140596459058944 DEBUG: ### XSqueeze-1.1.1 ### Still waiting for artistslideshow to stop
18:31:39 T:140595116881664 DEBUG: Previous line repeats 4 times.Any ideas?
2014-08-26, 03:20
Yeah latest Artist Slideshow quitting seems to be an issue.
I've just updated XSqueeze - it now closes irregardless of whether AS says it has exited cleanly after a (configurable) 4 second default. See the new 'troubleshooting' settings page. Even setting this down to one second and closing before AS exits appears to work ok with limited testing but in the past this caused crashes (which is why the wait was implemented originally). Fingers crossed other changes have in xbmc python process handling have stopped these crashes (in which case set it to 0 for fastest exit!).
Also fixed some potential but rare errors with unicode characters, and updated squeezelite binaries to latest.
Let me know how you go!
I've just updated XSqueeze - it now closes irregardless of whether AS says it has exited cleanly after a (configurable) 4 second default. See the new 'troubleshooting' settings page. Even setting this down to one second and closing before AS exits appears to work ok with limited testing but in the past this caused crashes (which is why the wait was implemented originally). Fingers crossed other changes have in xbmc python process handling have stopped these crashes (in which case set it to 0 for fastest exit!).
Also fixed some potential but rare errors with unicode characters, and updated squeezelite binaries to latest.
Let me know how you go!
2014-08-26, 04:05
My original SB3 has finally given up the ghost and I came across this excellent XBMC plugin–thank you!
I'm running Raspbmc on a Raspberry Pi. I managed to get everything up and working, however I'm finding the player/visualizer seems to bog down after starting to play a song. I'm wondering if the slideshow is simply too intensive for something like the Pi (I do have other stand-alone Pis running Squeezeslave with no issues).
Is there a way to disable the screensaver and just have a static image/blank screen? Is this something I should be dropping down to the CLI to test?
cheers,
J.
I'm running Raspbmc on a Raspberry Pi. I managed to get everything up and working, however I'm finding the player/visualizer seems to bog down after starting to play a song. I'm wondering if the slideshow is simply too intensive for something like the Pi (I do have other stand-alone Pis running Squeezeslave with no issues).
Is there a way to disable the screensaver and just have a static image/blank screen? Is this something I should be dropping down to the CLI to test?
cheers,
J.
2014-08-26, 05:16
Hey
I am pretty sure that it's not the AS stuff but the polling...I just think it's all too CPU intensive for the Pi.
But - you can try it easily by commenting out some lines in NowPlayingWindow.py around ~250:
# log("Starting ArtistSlideshow thread")
# self.thread2 = threading.Thread(target=self.runArtistSlideshow)
# self.thread2.setDaemon(True)
# self.thread2.start()
This is in the addon dir/script.xsqueeze/resources/lib/classes/
Just put the hashes in front.
Let me know what, if any, effect that has.
Actually, another easy thing to try if you're game - in the method below that (called update), change the top few lines to:
Note in python indentation is critical so it has to look like that...
This basically makes xbmc sleep a bit between updating the GUI, reducing the work a lot I think. Might well have a positive effect on the Pi (and doesn't seem to cause any trouble on other platforms in some quick testing)
Can you try those two things, especially this second one, and let me know?
I am pretty sure that it's not the AS stuff but the polling...I just think it's all too CPU intensive for the Pi.
But - you can try it easily by commenting out some lines in NowPlayingWindow.py around ~250:
# log("Starting ArtistSlideshow thread")
# self.thread2 = threading.Thread(target=self.runArtistSlideshow)
# self.thread2.setDaemon(True)
# self.thread2.start()
This is in the addon dir/script.xsqueeze/resources/lib/classes/
Just put the hashes in front.
Let me know what, if any, effect that has.
Actually, another easy thing to try if you're game - in the method below that (called update), change the top few lines to:
Code:
def update(self):
while self.running:
#don't need the lock to sleep...and don't need to thash this machine...
log("Sleep baby sleep, for a while...")
xbmc.sleep(500)
log("Ok, update the GUI after your rest you lazy bugger...")
with self.lock:
if constants.PLAYERTYPE=="squeezeslave":
self.updateLineDisplay()
(...etc... leave the rest as is)Note in python indentation is critical so it has to look like that...
This basically makes xbmc sleep a bit between updating the GUI, reducing the work a lot I think. Might well have a positive effect on the Pi (and doesn't seem to cause any trouble on other platforms in some quick testing)
Can you try those two things, especially this second one, and let me know?
2014-08-26, 16:55
Thank you for the quick response, this is a fantastic project and I appreciate that you still support it after all this time!
(2014-08-26, 03:20)bossanova808 Wrote: Yeah latest Artist Slideshow quitting seems to be an issue.
I've just updated XSqueeze - it now closes irregardless of whether AS says it has exited cleanly after a (configurable) 4 second default. See the new 'troubleshooting' settings page. Even setting this down to one second and closing before AS exits appears to work ok with limited testing but in the past this caused crashes (which is why the wait was implemented originally). Fingers crossed other changes have in xbmc python process handling have stopped these crashes (in which case set it to 0 for fastest exit!).
Also fixed some potential but rare errors with unicode characters, and updated squeezelite binaries to latest.
Let me know how you go!
2014-08-26, 19:45
I made the 2nd set of changes... everything is nice and responsive now on my Pi running Raspbmc. Thanks!
(2014-08-26, 05:16)bossanova808 Wrote: Hey
I am pretty sure that it's not the AS stuff but the polling...I just think it's all too CPU intensive for the Pi.
But - you can try it easily by commenting out some lines in NowPlayingWindow.py around ~250:
# log("Starting ArtistSlideshow thread")
# self.thread2 = threading.Thread(target=self.runArtistSlideshow)
# self.thread2.setDaemon(True)
# self.thread2.start()
This is in the addon dir/script.xsqueeze/resources/lib/classes/
Just put the hashes in front.
Let me know what, if any, effect that has.
Actually, another easy thing to try if you're game - in the method below that (called update), change the top few lines to:
Code:def update(self):
while self.running:
#don't need the lock to sleep...and don't need to thash this machine...
log("Sleep baby sleep, for a while...")
xbmc.sleep(500)
log("Ok, update the GUI after your rest you lazy bugger...")
with self.lock:
if constants.PLAYERTYPE=="squeezeslave":
self.updateLineDisplay()
(...etc... leave the rest as is)
Note in python indentation is critical so it has to look like that...
This basically makes xbmc sleep a bit between updating the GUI, reducing the work a lot I think. Might well have a positive effect on the Pi (and doesn't seem to cause any trouble on other platforms in some quick testing)
Can you try those two things, especially this second one, and let me know?
2014-08-27, 01:40
Ok, that's great - thanks for letting me know. And it's fine then with artist slideshow running, so just the second change is what is needed?
I'll do a release with this incorporated soon. Should have done this ages ago - think a lot of Pi users have been put off!
I'll do a release with this incorporated soon. Should have done this ages ago - think a lot of Pi users have been put off!
