Active Topics
-
Maemo repository (5)
to Community by dredlok706 - 1 day, 9 hrs ago -
Re-commissioning N9 in 2018 (127)
to MeeGo / Harmattan by smatkovi - 1 day, 12 hrs ago -
Porting apps to Leste (41)
to Maemo 7 / Leste by Arno_11 - 2 days, 5 hrs ago -
List of well performing apps on Leste (33)
to Maemo 7 / Leste by teroyk - 2 days, 14 hrs ago -
N900 is not recognizable on any of my devices (windows 10,7, xp) What can I do? (1)
to Nokia N900 by nieldk - 3 days, 18 hrs ago -
Error after installing Leste on sdcard (13)
to Maemo 7 / Leste by Maemish - 6 days, 21 hrs ago - more...
| The Following User Says Thank You to florian For This Useful Post: | ||
|
2010-12-05
, 19:13
|
|
Posts: 564 |
Thanked: 693 times |
Joined on Apr 2010
|
#362
|
The idea with a possibility to e.g,., add a button to sync a particular playlist would be great; I did consider that option already at the start, however the current version of the openspotify library does not support re-loading just a single (particular) playlist; playlist handling is automic and a single change to a playlist would require all the user's playlists to be reloaded. I have considered implementing a cache functionality, which would load the playlist and track data from a persistent local cache (and only in case that e.g, a playlists has been added / changed the playlists would need to be reloaded from the Spotify servers).
Originally Posted by florian
on the note of large playlists...
load each playlist on opening it.
Have a cache for the playlists.
Have an option in the titlebar menu (where FM transmitter is..) to "refresh" a single playlist.
That way, instead of on launch loading all data, the data is loaded in parts, however, through having a cache, it wouldn't slow down the user experience.
The added benefit of having a refresh button for a single playlist, is like a "sync" option, which might also be useful during runtime (outdated cache or I just added a song to that playlist on my computer).
| The Following User Says Thank You to aenbacka For This Useful Post: | ||
|
|
2010-12-08
, 12:09
|
|
Posts: 564 |
Thanked: 693 times |
Joined on Apr 2010
|
#363
|
I have been planning to integrate a change to the Now Playing queue handling in the next QSpot version (as a result of a bug report submitted by florian). When selecting a track for playback from the playlist view, all tracks of the playlist will be moved to the Now Playing view (and the track playing will be selected as is currently the case) . This way you do not need to return to the playlist view in case you want to listen to a track preceding the selected (playing) track. For search results I will preserve the existing behavior (i.e., all tracks following the selected one will be moved to Now Playing). This change will also impact shuffling, as all tracks of a playlist will be part of the shuffling queue. Any feedback on this is welcome as always..
| The Following 2 Users Say Thank You to aenbacka For This Useful Post: | ||
|
|
2010-12-13
, 09:20
|
|
Posts: 133 |
Thanked: 138 times |
Joined on Nov 2007
|
#365
|
The desktop Spotify clients support playlist folders. However, (at least) the iOS and QSpot mobile clients do not support playlist folders but just display all playlists in one long list.
Would it be possible to add support for playlist folders or is it simply not part of the libopenspotify library?
When you have many playlists, it is nice to be able to organize them using playlist folders.
Would it be possible to add support for playlist folders or is it simply not part of the libopenspotify library?
When you have many playlists, it is nice to be able to organize them using playlist folders.
| The Following User Says Thank You to generationally For This Useful Post: | ||
|
|
2010-12-13
, 18:08
|
|
Posts: 182 |
Thanked: 40 times |
Joined on Apr 2010
|
#366
|
I kind of fell off using this as the official iPhone client is just much more... well, honestly, a quantum leap in terms of usability especially now with multitasking, and I don't get the connectivity issues (I quit when I couldn't load any of my playlists about three months ago). I've checked on the latest version though - nice work / improvements so far 
The issues I've come up with so far are (all with wifi use):
- Stops playback after a while (i.e. before an album is completed). Not always but quite often. And no, I'm not logging on anywhere else.
- Grinds the phone down to almost a halt after it has been left without playback for a while (i.e. when the display goes back to sleep). I have to quit QSpot - which takes about a minute while I wait for the N900 to respond - in order to normalise the situation.
- High CPU use - drastically impacts battery
- Playlists often don't load, with a timeout error (I usually have around 80 playlists of individual albums). It's better than when I stopped using QSpot the last time where 9 times out of 10 playlists wouldn't load, but it's still like 3 times out of 10.
- Playback order is a bit off if you aren't using playlists - doesn't play by track but in a sorta-alphabetical order
Nice to haves as before:
- Offline
- Live playlist updates without needing to quit app
- Plus the stuff florian suggested
Last edited by punto; 2010-12-13 at 18:27.
The issues I've come up with so far are (all with wifi use):
- Stops playback after a while (i.e. before an album is completed). Not always but quite often. And no, I'm not logging on anywhere else.
- Grinds the phone down to almost a halt after it has been left without playback for a while (i.e. when the display goes back to sleep). I have to quit QSpot - which takes about a minute while I wait for the N900 to respond - in order to normalise the situation.
- High CPU use - drastically impacts battery
- Playlists often don't load, with a timeout error (I usually have around 80 playlists of individual albums). It's better than when I stopped using QSpot the last time where 9 times out of 10 playlists wouldn't load, but it's still like 3 times out of 10.
- Playback order is a bit off if you aren't using playlists - doesn't play by track but in a sorta-alphabetical order
Nice to haves as before:
- Offline
- Live playlist updates without needing to quit app
- Plus the stuff florian suggested
Last edited by punto; 2010-12-13 at 18:27.
| The Following User Says Thank You to punto For This Useful Post: | ||
|
|
2010-12-14
, 08:14
|
|
Posts: 564 |
Thanked: 693 times |
Joined on Apr 2010
|
#367
|
The library does not currently support playlist folders (it has only been introduced in the newest version of the official libspotify library). However, I could at some point look into whether it easily could be added..
Originally Posted by generationally
The desktop Spotify clients support playlist folders. However, (at least) the iOS and QSpot mobile clients do not support playlist folders but just display all playlists in one long list.
Would it be possible to add support for playlist folders or is it simply not part of the libopenspotify library?
When you have many playlists, it is nice to be able to organize them using playlist folders.
| The Following User Says Thank You to aenbacka For This Useful Post: | ||
|
|
2010-12-14
, 08:36
|
|
Posts: 564 |
Thanked: 693 times |
Joined on Apr 2010
|
#368
|
Originally Posted by punto
Thanks for your feedback, I have been trying to increase general stability of QSpot in the latest versions..
I kind of fell off using this as the official iPhone client is just much more... well, honestly, a quantum leap in terms of usability especially now with multitasking, and I don't get the connectivity issues (I quit when I couldn't load any of my playlists about three months ago). I've checked on the latest version though - nice work / improvements so far
The issues I've come up with so far are (all with wifi use):
- Stops playback after a while (i.e. before an album is completed). Not always but quite often. And no, I'm not logging on anywhere else.
- Grinds the phone down to almost a halt after it has been left without playback for a while (i.e. when the display goes back to sleep). I have to quit QSpot - which takes about a minute while I wait for the N900 to respond - in order to normalise the situation.
- High CPU use - drastically impacts battery
- Playlists often don't load, with a timeout error (I usually have around 80 playlists of individual albums). It's better than when I stopped using QSpot the last time where 9 times out of 10 playlists wouldn't load, but it's still like 3 times out of 10.
- Playback order is a bit off if you aren't using playlists - doesn't play by track but in a sorta-alphabetical order
Nice to haves as before:
- Offline
- Live playlist updates without needing to quit app
- Plus the stuff florian suggested
The sudden stop of playback is as already mentioned before in this thread related to libopenspotify, and I have not yet made any changes / fixes related to this problem. In many cases the playback is possible to manually resume (and this also happens more frequently on slower connections).
When you have experienced slowdown problems after using QSpot with the display off (sleep state), for approx. how long have you been playing, and e.g., using what bitrate? I have not myself noted such major slowdown problems; do you use e.g, swappolube or some other kernel parameter optimizations?
The high cpu usage is known, and it might be able to do some optimizations in that area; however handling of e.g., decompressing audio (ogg/vorbis) data by the library requires significant cpu (even more with higher bitrate).
I have also experienced problems with playlist loading now and then, and I think that one solution to this would be the introduction of offline playlist caching. E.g., as long as the playlists have not changed, they could be retrieved directly from the cache (this was already suggested by florian). Also the official Spotify clients retrieve playlist metadata from cache, and therefore they are often immediately available upon application startup.
When you refer to the playback order being a bit off, in what way would you prefer to have the tracks played? The search view currently offers several alternatives way to display / play the results.
The problem with offline mode is still the same; while it would be possible to implement from a technical point of view it will not be introduced in QSpot as this functionality can only be offered by the official Spotify clients (due to e.g, copyright etc. restrictions).
I will need to investigate whether live updates of playlist would be possible to implement.
|
|
2010-12-14
, 11:32
|
|
Posts: 182 |
Thanked: 40 times |
Joined on Apr 2010
|
#369
|
Yeah- it's a shame about offline, I understand why it's not a practical possibility at the moment. It is however the primary requirement for a mobile Spotify client, so that's the reason I don't really use QSpot as more than a bath-side player at the moment (perching a laptop on the toilet or tank lid is... well, not a great idea) 
A typical scenario is that I have it as the abovementioned bath-side player. Say it quit three-quarters of a way through a comedy album, but I didn't get out of the bath to do anything about it, and instead switch to reading this month's NatG. Say I pick up the N900 when I'm done with the bath and put it elsewhere without further intervention.
(So all this time, QSpot is in the foreground still)
Now, say I pick it up again later that evening. What happens is that it takes the N900 takes about 10-30 seconds to wake up (blank, but lit, screen) and is very sluggish to respond once you're back in QSpot. Switching to anything else, just as sluggish. However if you quit QSpot, everything returns to normal. The process to wake it up and quit out of the slowly responding QSpot takes around 30 secs - 1 minute (haven't timed it exactly).
In this scenario, the battery is also being excessively discharged. Just the action of keeping QSpot running seems to consume huge amounts of extra power. e.g. I used QSpot to play one <120-minute playlist when going to bed with a full charge (wifi radio on, GSM/BT radio off), and now, the morning after the N900 is almost empty.
This is an almost clean PR 1.3 (whatever the current is) install - I'd actually prepped the N900 to sell, but when I looked at the resale prices in this area I thought "**** this, I get less than a 2-year-old iPhone 3G with half the RAM for it? I'm keeping it and getting my money's worth, dammit!"
Control panel extensions: Tweakr
System extensions: Cellular Modem Control Buttons, rootsh, Wifi Switcher
Usually nothing else is running when QSpot is, although I might crank up MicroB for a quick browse of something.
Last edited by punto; 2010-12-14 at 11:48.
Originally Posted by aenbacka
I now put it in Standard bitrate as 320K seems to sometimes result in more issues.
When you have experienced slowdown problems after using QSpot with the display off (sleep state), for approx. how long have you been playing, and e.g., using what bitrate? I have not myself noted such major slowdown problems; do you use e.g, swappolube or some other kernel parameter optimizations?
A typical scenario is that I have it as the abovementioned bath-side player. Say it quit three-quarters of a way through a comedy album, but I didn't get out of the bath to do anything about it, and instead switch to reading this month's NatG. Say I pick up the N900 when I'm done with the bath and put it elsewhere without further intervention.
(So all this time, QSpot is in the foreground still)
Now, say I pick it up again later that evening. What happens is that it takes the N900 takes about 10-30 seconds to wake up (blank, but lit, screen) and is very sluggish to respond once you're back in QSpot. Switching to anything else, just as sluggish. However if you quit QSpot, everything returns to normal. The process to wake it up and quit out of the slowly responding QSpot takes around 30 secs - 1 minute (haven't timed it exactly).
In this scenario, the battery is also being excessively discharged. Just the action of keeping QSpot running seems to consume huge amounts of extra power. e.g. I used QSpot to play one <120-minute playlist when going to bed with a full charge (wifi radio on, GSM/BT radio off), and now, the morning after the N900 is almost empty.
This is an almost clean PR 1.3 (whatever the current is) install - I'd actually prepped the N900 to sell, but when I looked at the resale prices in this area I thought "**** this, I get less than a 2-year-old iPhone 3G with half the RAM for it? I'm keeping it and getting my money's worth, dammit!"
Control panel extensions: Tweakr
System extensions: Cellular Modem Control Buttons, rootsh, Wifi Switcher
Usually nothing else is running when QSpot is, although I might crank up MicroB for a quick browse of something.
Last edited by punto; 2010-12-14 at 11:48.
| The Following User Says Thank You to punto For This Useful Post: | ||
|
|
2010-12-14
, 12:04
|
|
Posts: 564 |
Thanked: 693 times |
Joined on Apr 2010
|
#370
|
Thanks a lot for the clarifications and comments; I still would like to ask that when you have tried to open the display (and the device has been sluggish), in what state has QSpot been? I.e., has it played the album etc. to end (and should essentially be in idle state)?
Originally Posted by punto
Yeah- it's a shame about offline, I understand why it's not a practical possibility at the moment. It is however the primary requirement for a mobile Spotify client, so that's the reason I don't really use QSpot as more than a bath-side player at the moment (perching a laptop on the toilet or tank lid is... well, not a great idea)
I now put it in Standard bitrate as 320K seems to sometimes result in more issues.
A typical scenario is that I have it as the abovementioned bath-side player. Say it quit three-quarters of a way through a comedy album, but I didn't get out of the bath to do anything about it, and instead switch to reading this month's NatG. Say I pick up the N900 when I'm done with the bath and put it elsewhere without further intervention.
(So all this time, QSpot is in the foreground still)
Now, say I pick it up again later that evening. What happens is that it takes the N900 takes about 10-30 seconds to wake up (blank, but lit, screen) and is very sluggish to respond once you're back in QSpot. Switching to anything else, just as sluggish. However if you quit QSpot, everything returns to normal. The process to wake it up and quit out of the slowly responding QSpot takes around 30 secs - 1 minute (haven't timed it exactly).
In this scenario, the battery is also being excessively discharged. Just the action of keeping QSpot running seems to consume huge amounts of extra power. e.g. I used QSpot to play one <120-minute playlist when going to bed with a full charge (wifi radio on, GSM/BT radio off), and now, the morning after the N900 is almost empty.
This is an almost clean PR 1.3 (whatever the current is) install - I'd actually prepped the N900 to sell, but when I looked at the resale prices in this area I thought "**** this, I get less than a 2-year-old iPhone 3G with half the RAM for it? I'm keeping it and getting my money's worth, dammit!"
Control panel extensions: Tweakr
System extensions: Cellular Modem Control Buttons, rootsh, Wifi Switcher
Usually nothing else is running when QSpot is, although I might crank up MicroB for a quick browse of something.
 |
| Tags |
| premium account, spotify |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 01:46.
load each playlist on opening it.
Have a cache for the playlists.
Have an option in the titlebar menu (where FM transmitter is..) to "refresh" a single playlist.
That way, instead of on launch loading all data, the data is loaded in parts, however, through having a cache, it wouldn't slow down the user experience.
The added benefit of having a refresh button for a single playlist, is like a "sync" option, which might also be useful during runtime (outdated cache or I just added a song to that playlist on my computer).