Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 1 day, 10 hrs ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 2 days, 5 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 4 days, 14 hrs ago - more...
|
2010-12-20
, 09:32
|
|
Posts: 564 |
Thanked: 693 times |
Joined on Apr 2010
|
#383
|
Ok, thanks for the information, I just wanted to ask so that all possible factors can be taken into account (I have myself not power kernel installed). However, I am now also working on other optimizations to QSpot that I hope will help.
Originally Posted by Nozu
I'm using power kernel. o/
|
|
2010-12-20
, 10:03
|
|
Posts: 564 |
Thanked: 693 times |
Joined on Apr 2010
|
#384
|
Also, would it be possible for some of you with the responsiveness problem to post e.g., output of top from xterminal when the device is becoming sluggish. This could be of help trying to locate the problem / cause.
|
|
2010-12-20
, 18:53
|
|
Posts: 182 |
Thanked: 40 times |
Joined on Apr 2010
|
#385
|
Next time it happens I'll post up the terminal results. I have pretty much slunk back to the iPhone for my Spotifying, and I've bought a Touch - so it might be a while.
Also, I should mention the issue with playlists as briefly mentioned before. 160kbps playback results in playlists loading 6-7 times out of 10 launches, but 320K results in fewer successes for some reason. Also - would it be possible to have a bitrate indication during playback? I suspect some tracks are in 160K despite high bitrate selected - and I'd like to make sure my ears aren't playing tricks on me
Also, I should mention the issue with playlists as briefly mentioned before. 160kbps playback results in playlists loading 6-7 times out of 10 launches, but 320K results in fewer successes for some reason. Also - would it be possible to have a bitrate indication during playback? I suspect some tracks are in 160K despite high bitrate selected - and I'd like to make sure my ears aren't playing tricks on me
| The Following User Says Thank You to punto For This Useful Post: | ||
|
|
2010-12-20
, 19:01
|
|
Posts: 564 |
Thanked: 693 times |
Joined on Apr 2010
|
#386
|
Originally Posted by punto
An interesting observation concerning the playlists; it should not have any difference whether the selected bitrate is 160k or 320k for the playlist loading, but I will check it out in case there is some problems present in handling of higher bitrate. The bitrate info is available for each track, so it should be possible to display it..
Next time it happens I'll post up the terminal results. I have pretty much slunk back to the iPhone for my Spotifying, and I've bought a Touch - so it might be a while.
Also, I should mention the issue with playlists as briefly mentioned before. 160kbps playback results in playlists loading 6-7 times out of 10 launches, but 320K results in fewer successes for some reason. Also - would it be possible to have a bitrate indication during playback? I suspect some tracks are in 160K despite high bitrate selected - and I'd like to make sure my ears aren't playing tricks on me
However, it is not currently exposed by the library so it will need to be added. All tracks are indeed not available in high bitrate, and in such case, the standard bitrate 160k is automatically selected.
|
|
2010-12-20
, 19:41
|
|
Posts: 726 |
Thanked: 345 times |
Joined on Apr 2010
@ Sweden
|
#387
|
Just a quick observation from my own Spotify client development:
If the openspotify library uses threads to manage reading and delivering of (meta) data, it might be interesting to look into how the locking works. Data starvation, as in the connection to the Spotify server becoming slow or stalling, might make a naïve reader thread implementation very slow spending time exchanging locks with the delivery thread while polling for more data that isn't arriving.
I had exactly this problem caused by an, on the surface, innocent change of ordering of lock handling in the code.
If the openspotify library uses threads to manage reading and delivering of (meta) data, it might be interesting to look into how the locking works. Data starvation, as in the connection to the Spotify server becoming slow or stalling, might make a naïve reader thread implementation very slow spending time exchanging locks with the delivery thread while polling for more data that isn't arriving.
I had exactly this problem caused by an, on the surface, innocent change of ordering of lock handling in the code.
| The Following User Says Thank You to Joorin For This Useful Post: | ||
|
|
2010-12-20
, 20:15
|
|
Posts: 564 |
Thanked: 693 times |
Joined on Apr 2010
|
#388
|
Originally Posted by Joorin
Thanks for the observation, it is indeed very possible that locking is the cause for many problems in the library (there are several thread synchronization issues present, hopefully it will be possible to sort them out). Concerning playlist loading, it seems that the same behaviour is also present in the clients using the despotify library (i.e,. when there has bee problem loading playlists in QSpot I have observed the same behaviour with e.g., yaspot and footify). Data starvation seems like a good explanation to the problems, some more debugging will need to be done.
Just a quick observation from my own Spotify client development:
If the openspotify library uses threads to manage reading and delivering of (meta) data, it might be interesting to look into how the locking works. Data starvation, as in the connection to the Spotify server becoming slow or stalling, might make a naïve reader thread implementation very slow spending time exchanging locks with the delivery thread while polling for more data that isn't arriving.
I had exactly this problem caused by an, on the surface, innocent change of ordering of lock handling in the code.
|
|
2010-12-20
, 23:55
|
|
Posts: 182 |
Thanked: 40 times |
Joined on Apr 2010
|
#389
|
Originally Posted by aenbacka
Yeah - that's what I would assume as well.
An interesting observation concerning the playlists; it should not have any difference whether the selected bitrate is 160k or 320k for the playlist loading, but I will check it out in case there is some problems present in handling of higher bitrate. The bitrate info is available for each track, so it should be possible to display it..
Thing is, since I switched over to 320K this evening (and quit every time an album finished or I wanted to switch albums), I've had three instances of 'forever spinning' (i.e. nothing loading, activity indicator keeps spinning, no timeout it seems - give up after 5 mins or so), and ten instances of playlists only partially loading with a timeout - i.e. only two fully successful launches out of fifteen.
I switched to 160Kbs and the playlists loaded first time after that. It did fail the next time though... but it loaded after that, again.
No traffic restrictions - The N900 is on my cable LAN, which has 10Mb down.
Another question:
I keep prodding on the progress bar expecting it to do something. Should it (i.e. scrub)?
|
|
2010-12-21
, 04:06
|
|
Posts: 564 |
Thanked: 693 times |
Joined on Apr 2010
|
#390
|
Originally Posted by punto
Yeah - that's what I would assume as well.
Thing is, since I switched over to 320K this evening (and quit every time an album finished or I wanted to switch albums), I've had three instances of 'forever spinning' (i.e. nothing loading, activity indicator keeps spinning, no timeout it seems - give up after 5 mins or so), and ten instances of playlists only partially loading with a timeout - i.e. only two fully successful launches out of fifteen.
I switched to 160Kbs and the playlists loaded first time after that. It did fail the next time though... but it loaded after that, again.
No traffic restrictions - The N900 is on my cable LAN, which has 10Mb down.
Another question:
I keep prodding on the progress bar expecting it to do something. Should it (i.e. scrub)?
Well the fact that playlist loading success ratio is much higher using 160k bitrate does indicate some problem with the high bitrate option. That option has been added later to the library, so there could be some difference in the internal handling. I will look into it.
The idea is that you should be able to seek within a track using the progress bar; however the seek functionality is not yet implemented, I hope to add it to a future version of QSpot.
 |
| Tags |
| premium account, spotify |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 11:07.
It is true indeed (however the sleep timer functionality has been requested earlier already so I had intention to add it anyway at some point). This problem needs to be solved in a general way (either by modifications to the underlying library, or to QSpot itself). I will need to investigate the memory usage in more detail, however of some reason I am not myself able to trigger the same condition very easily. By the way, do any one you that are experiencing this problem happen to be using the power kernel?