updated: sspopartsq (animated screen saver), kinamp, kaffeine (keeps kindle awake)

[ryran]

Wow. Not sure how I missed that in my testing & setup. I guess that's sometimes the problem with thinking too much. Heh. As a work-around, I ended up using LP to call a script that conditionally killed kinamp or started it. I was happy with it.

After chopping all that down to a cd & a kinamp command, everything works fine. So it appears that if kinamp is already running and you execute it, it quits regardless of any args you pass it. I should've known it would be so simple. Thanks again fbdev.

3 More questions.
Q1: Have you noticed any problems after using kinamp to pause mplayer for extended periods of time? From watching ps output for a spell, it seems to me like there's no cpu or RAM leakage, but if I could work out a simple enough way for the mplayer/kinamp/launchpad combo to easily remember my place in the current playlist, I'd be happy to shut it all down between sessions.

Q2: All of my music is VBR. So I'm interested in disabling the progress bar, as damn-impressive as it is, to save on battery life. I'm not a developer, but I'm an SA extremely well-versed in BASH who has also played around with modding other open source projects to my liking. I've had a glance at the source for kinamp and was wondering if you could point me in the right direction? How much would I need to change? (I see the progressbar struct.. simple as commenting that out? *grin*) On the other hand, how much would YOU need to change to add a kinamp parameter that disabled the prog bar? (I'm guessing "a lot", since you pass all args on to mplayer.)

Q3: I have lots of music that flows from track to track and sounds silly on a player that doesn't have gapless playback. One of my dreams in rooting my Kindle was that I'd find an mp3 player that could do gapless... Do you know if mplayer has always been bad at gapless music playback or is this a symptom of the way it was compiled for the Kindle?

Thanks for your time fbdev.

[fbdev]

a suggestion; i think another user hinted at this; is to use kaffeine with kinamp (or the kindle's audio player) so that audio will continue to play while the screensaver is active.

without kaffeine the system will enter standby mode (after about 70 seconds) and audio will stop.

[fbdev]

if your kindle goes to standby mplayer will choke even if paused. this i a bug in mplayer related to the seek bug.

wrt remembering your location on a playlist, that is more complicated. i'm going to have to leave you to your own devices.

the progress bar does not require any significant amount of cpu time. it is a bit of a garish eyesore with vbr though ::glares needles at mplayer::

my suggestion is to re-encode audio to cbr. it's pretty easy; there are plenty of utilities you can use to batch it.

i don't like mplayer's lack of gapless track switching, either. i think i read somewhere that they aren't interested in fixing it at all. if you can find another slave player that i can use as the backend for the ui, i'd be happy to port it.

here's the method that repaints the progress bar:
void
repaintpercent()
{
bgonly(); setbg(15);
rectangle(0,798,600,2);
setbg(0);
rectangle(0,798,6 * percent,2);
repaint();
}

just do this:
void
repaintpercent()
{
return;
bgonly(); setbg(15);
rectangle(0,798,600,2);
setbg(0);
rectangle(0,798,6 * percent,2);
repaint();
}

and it should go away.

Originally Posted by ryran

Wow. Not sure how I missed that in my testing & setup. I guess that's sometimes the problem with thinking too much. Heh. As a work-around, I ended up using LP to call a script that conditionally killed kinamp or started it. I was happy with it.

After chopping all that down to a cd & a kinamp command, everything works fine. :) So it appears that if kinamp is already running and you execute it, it quits regardless of any args you pass it. I should've known it would be so simple. Thanks again fbdev. :D

3 More questions.
Q1: Have you noticed any problems after using kinamp to pause mplayer for extended periods of time? From watching ps output for a spell, it seems to me like there's no cpu or RAM leakage, but if I could work out a simple enough way for the mplayer/kinamp/launchpad combo to easily remember my place in the current playlist, I'd be happy to shut it all down between sessions.

Q2: All of my music is VBR. So I'm interested in disabling the progress bar, as damn-impressive as it is, to save on battery life. I'm not a developer, but I'm an SA extremely well-versed in BASH who has also played around with modding other open source projects to my liking. I've had a glance at the source for kinamp and was wondering if you could point me in the right direction? How much would I need to change? (I see the progressbar struct.. simple as commenting that out? *grin*) On the other hand, how much would YOU need to change to add a kinamp parameter that disabled the prog bar? (I'm guessing "a lot", since you pass all args on to mplayer.)

Q3: I have lots of music that flows from track to track and sounds silly on a player that doesn't have gapless playback. One of my dreams in rooting my Kindle was that I'd find an mp3 player that could do gapless... Do you know if mplayer has always been bad at gapless music playback or is this a symptom of the way it was compiled for the Kindle?

Thanks for your time fbdev.

[CaelThunderwing]

ok i think i made tyhe ini right for Kaffine,

[Actions]
;; run kaffeine
K O = !/mnt/us/launchpad/kaffeine &

K S = !/mnt/us/launchpad/kaffeine s &

if i wanted it to prevent both standby/sc reen saver (in my case only screensaver as its a KSO

but what do i need to ad to kill it via shortcut?

[fbdev]

Originally Posted by CaelThunderwing

ok i think i made tyhe ini right for Kaffine,

[Actions]
;; run kaffeine
K O = !/mnt/us/launchpad/kaffeine &

K S = !/mnt/us/launchpad/kaffeine s &

if i wanted it to prevent both standby/sc reen saver (in my case only screensaver as its a KSO

but what do i need to ad to kill it via shortcut?

to kill it you use the same shortcut as to run it. the application will toggle.

[ryran]

Originally Posted by fbdev

a suggestion; i think another user hinted at this; is to use kaffeine with kinamp (or the kindle's audio player) so that audio will continue to play while the screensaver is active.

without kaffeine the system will enter standby mode (after about 70 seconds) and audio will stop.

It took me a while to notice that ^ because I was doing all my testing with the K3 connected to my PC via usbnet and [despite what you've posted elsewhere] my kindle doesn't go into standby when plugged in like that. ALSO, the built-in mp3 player doesn't ever stop playing after my kindle screensaver comes on; it doesn't stop until reaching the end of it's playlist. (This is not the case if I enable the password lock.)

I've setup kaffeine via launchpad with some sh magic... and I'm no stranger to keeping things simple and sticking to UNIX philosophy (i.e. small apps that do one thing well), but in this case I think there's an argument for keeping the standby functionality hard-coded into kinamp, a la v0 or the stock mp3 player. I can work around it by using a script that starts both kaffeine and kinamp though... I'm curious to hear what your ideas in that decision were. I don't have horribly strong feelings one way or the other.

I DO think it would be awesome to add some capability to kaffeine (right after you finished making it simpler *grin*). Namely, the ability to take an optional argument: time. Currently I do this with a launcher script that toggles kaffeine, sleeps for X minutes and then turns it off. I'm fine with that, but this feature seems like a pretty logical next step, depending on how complicated it makes the binary (it is after all pretty easy to implement with a script).

Thanks for reading fbdev!

[ryran]

Originally Posted by fbdev

1) the progress bar does not require any significant amount of cpu time. ... 2) my suggestion is to re-encode audio to cbr. ... 3) if you can find another slave player that i can use as the backend for the ui, i'd be happy to port it.

4) here's the method that repaints the progress bar:
... just do this: ...

1. I could see that it didn't use much cpu time; I was more thinking about the power required by the display to be constantly updating those few pixels on the bottom. Do you think that's negligible as well?

2. I hear ya. I have no interest in transcoding my files, especially not to any format in CBR. Thanks for the suggestion tho.

3. I'm amazed how well mplayer works now! I tried the mplayer that's posted elsewhere on this board first and was totally disappointed that it was using 50% of the cpu. I was psyched when I saw your compile of it was using similar time as the stock player. I'll keep an eye out though...

4. THANK YOU. So simple! Should've known. When I have some more time I'll get scratchbox set up on my ubuntu install (mostly use fedora). I'd like to tweak the kinamp hotkeys too. Oh--that reminds me: Can you explain your choice of keys for that? (It seems kinda un-intuitive that next is to the left of prev. I'm also surprised you didn't use the dpad.)

Kinamp feature request: I'd love to have a hotkey to paint the currently-playing track. I have some long files.

[fbdev]

1: considering that you are playing music i wouldn't suspect that switching a few pixels would only consume a negligible amount of additional mW.

if you want to find out for sure, run the native audio player for a few hours, note the batt%, charge the device and run kinamp over the same time period.

here's a command to check your battery percent:
dbus-send --system --print-reply --dest=com.lab126.powerd /default com.lab126.powerd.getstatusStr

i would test with wireless off.

2: flac is cbr, if it's a quality thing. if not, mp3 @ 128kbit cbr should only produce a little distortion in the highs.

4: maybe i'll code a version with assignable keybindings. i've thought about it from the time i wrote it but i was waiting to see if there was any interest. after all, if i want different keybindings, i just recompile. =]

that's a good feature request. i want to get the fade out bug corrected before i start adding anything, though. perhaps it's just artistic neurosis; an artist always see the tiniest flaws and blows them out of proportion; but that's my first priority.

Originally Posted by ryran

1. I could see that it didn't use much cpu time; I was more thinking about the power required by the display to be constantly updating those few pixels on the bottom. Do you think that's negligible as well?

2. I hear ya. I have no interest in transcoding my files, especially not to any format in CBR. Thanks for the suggestion tho. ;)

3. I'm amazed how well mplayer works now! I tried the mplayer that's posted elsewhere on this board first and was totally disappointed that it was using 50% of the cpu. I was psyched when I saw your compile of it was using similar time as the stock player. I'll keep an eye out though...

4. THANK YOU. So simple! Should've known. When I have some more time I'll get scratchbox set up on my ubuntu install (mostly use fedora). I'd like to tweak the kinamp hotkeys too. Oh--that reminds me: Can you explain your choice of keys for that? (It seems kinda un-intuitive that next is to the left of prev. I'm also surprised you didn't use the dpad.)

Kinamp feature request: I'd love to have a hotkey to paint the currently-playing track. I have some long files.

[fbdev]

apparently i was speaking ccomment (the sloppy english that accompanies code =])

Originally Posted by fbdev

1: considering that you are playing music i wouldn't suspect that switching a few pixels would only consume a negligible amount of additional mW.

[yangwenli]

hi，thanks for your kaffeine。
Could you make it auto-start after kindle reboot?

[ryran]

Originally Posted by fbdev

here's a command to check your battery percent:
dbus-send --system --print-reply --dest=com.lab126.powerd /default com.lab126.powerd.getstatusStr
... an artist always see the tiniest flaws and blows them out of proportion; but that's my first priority.

Oh my that is some lovely output. Gracias un otra vez.
And I totally understand. I think I'm the same way with my bash scripting.

[ryran]

Hey fbdev.
Today for the first time I kicked off kinamp without -loop 0 ... and was quite surprised at what happened when mplayer reached the end of it's playlist: mplayer became a zombie and kinamp started pegging the cpu. 0_o

Running kinamp again worked as normal -- namely, kinamp shut down it's defunct mplayer process & itself but uhh.... that's not cool.

Any thoughts?

[EDIT]
Do you have any music files that have international characters in their file names? I do. A lot. It seems that when kinamp is trying to display the currently-playing file: as soon as it reaches a character with [e.g.] an accent, it stops reading the rest of the file name for display. This doesn't affect the music; only the visual aspect.

[fbdev]

thanks for the bug.

let me know if this fixes it.

Originally Posted by ryran

Hey fbdev.
Today for the first time I kicked off kinamp without -loop 0 ... and was quite surprised at what happened when mplayer reached the end of it's playlist: mplayer became a zombie and kinamp started pegging the cpu. 0_o

Running kinamp again worked as normal -- namely, kinamp shut down it's defunct mplayer process & itself but uhh.... that's not cool.

Any thoughts?

[ryran]

Ah. Very nice. That simplifies things.

[ChaosZeroX]

Can you make an install/useage guide for kindle noobs like me