<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.systems.archos.rockbox.devel">
    <title>gmane.comp.systems.archos.rockbox.devel</title>
    <link>http://blog.gmane.org/gmane.comp.systems.archos.rockbox.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10648"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10647"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10646"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10645"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10644"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10643"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10642"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10641"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10640"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10639"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10638"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10637"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10636"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10635"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10634"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10633"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10632"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10631"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10630"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10629"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10648">
    <title>Re: [ata] wait_for_bsy vs. wait_for_rdy: ATA spec interpretation</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10648</link>
    <description>&lt;pre&gt;2012/5/7 Jonas Wielicki &amp;lt;j.wielicki&amp;lt; at &amp;gt;sotecware.net&amp;gt;:

More versions of the standard can be found at
http://hddguru.com/documentation (including recent ones)


From this point of view this is correct. I mean state diagram for PIO
commands doesn't mention DRDY bit.
BUT section 5.14.5.2 of ATA/ATAPI-7 spec states that all devices not
implementing PACKET command feature set (aka CDROMs)
should set DRDY to 1 when device is capable of accepting commands.
Moreover it states that device should preserve DRDY state in idle and
standby modes.

Anyway I am by no means ATA expert so more experienced devs should
express their opinion here.

MB


&lt;/pre&gt;</description>
    <dc:creator>Marcin Bukat</dc:creator>
    <dc:date>2012-05-08T07:52:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10647">
    <title>Re: How to debug gapless issues?</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10647</link>
    <description>&lt;pre&gt;When I tried to run that on my device, it blackscreen'd a part of a
second after the initial rockbox splash comes up (rockbox logo + build
id). It still runs, but does not react to key input, only way to bring
it back to live is to short the Reset pins.

Is there any possible explanation for this behaviour?

&lt;/pre&gt;</description>
    <dc:creator>Jonas Wielicki</dc:creator>
    <dc:date>2012-05-07T18:08:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10646">
    <title>[ata] wait_for_bsy vs. wait_for_rdy: ATA spec interpretation</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10646</link>
    <description>&lt;pre&gt;Hi folks,

(heh, I hope this won't be too long, but its essentially just a short
question with a „bit“ of context)

I'm still messing with ATA code to debug further SSD issues. Now I
stumbled across what rockbox code does before command issuing. Basically
its like this:

(1) Select the device
(2) wait_for_rdy
(2a) wait_for_bsy (or return with error)
(2a.i) wait until STATUS_BSY is cleared (or timeout)
(2a) wait until STATUS_RDY is set (or timeout)
(3) Setup parameters and issue the command

(see firmware/ata.c, searching for ATA_SELECT for reference, its done at
several places)

However, ATA spec draft 5 (section 9.3, its at page 236 in the version I
have) has the following state graph for the bus idle mode (i.e. before a
command is being executed):


Check_Status:
    BSY = 0 &amp;amp; DRQ = 0 &amp;amp; wrong device selected
      =&amp;gt; Device_Select
    BSY = 0 &amp;amp; DRQ = 0 &amp;amp; correct device selected
      =&amp;gt; Write_parameters
    BSY = 1 or DRQ = 1
      =&amp;gt; Check_Status
Device_Select:
    Device selected
      =&amp;gt; Check_Status
Write_parameters:
    ... do command setup etc.


So the spec makes no statement about the RDY bit in the status register,
so we could be timing out here indefinetly under circumstances where the
RDY bit has *not* been set before or am I getting something wrong here?

The reason I'm looking so closely right now is that I get weird timeouts
which I tracked down to wait_for_rdy to fail after device selection.

So I'm just asking back because it seems like this should have lead to
issues before, except if my drive behaves significantly different from
all other drives used in rockbox players. I'm currently testing with
just waiting for BSY to clear, which does not give me issues until now
(however, thats no safe indicator, as the issues I have seem a bit racey).

Summarized:
(1) are we missing a subtle point in the ATA spec here?
(2) if so, why does it not cause errors with most (all) drives?
(2a) maybe due to numerous reset attempts which give RDY bits?
(2a.i) if so, why do these fail on my drive?

cheers,
Jonas

&lt;/pre&gt;</description>
    <dc:creator>Jonas Wielicki</dc:creator>
    <dc:date>2012-05-07T16:21:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10645">
    <title>Re: How to debug gapless issues?</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10645</link>
    <description>&lt;pre&gt;

You need to select logf in configure (under the advanced options) too.
But when I tested enabling logf in playback.c, there were some bitrot,
and even typos, that needs to be fixed.

&lt;/pre&gt;</description>
    <dc:creator>Magnus Holmgren</dc:creator>
    <dc:date>2012-05-07T10:17:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10644">
    <title>Re: How to debug gapless issues?</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10644</link>
    <description>&lt;pre&gt;
Okay, this is probably me being stupid, but the only log related thing I
can find in the Debug menu is called “Metadata log”. However the only
effect selecting and hitting NAVI has is that a popup shows up with
“Metadata log enabled” (or “disabled”, it toggles).


Well, I just turned it on as it has been a suggestion in the bugtracker
when I looked for gapless-related bugs to trace it down. The pcm buffer
starves always for me, at least with the SSD.

&lt;/pre&gt;</description>
    <dc:creator>Jonas Wielicki</dc:creator>
    <dc:date>2012-05-07T07:28:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10643">
    <title>RE: How to debug gapless issues?</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10643</link>
    <description>&lt;pre&gt;
Does crossfade even need to do a disk access?  If both files are buffered and are the same format, I think it shouldn't unless the codec buffer happened to empty right at the track change, which seems unlikely.  

Do these specific files work normally in the uisim on your PC with crossfade enabled?       &lt;/pre&gt;</description>
    <dc:creator>Mike Giacomelli</dc:creator>
    <dc:date>2012-05-06T19:08:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10642">
    <title>Re: How to debug gapless issues?</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10642</link>
    <description>&lt;pre&gt;

It goes to a buffer you can view in the debug menu (and write it to disk). 
Define LOGF_ENABLE in the files where you want logging to happen, and any LOGF 
calls will go to that buffer.


Don't know if crossfade makes things different, but without crossfade the pcm 
buffer doesn't starve on track change on my FuzeV2.

&lt;/pre&gt;</description>
    <dc:creator>Magnus Holmgren</dc:creator>
    <dc:date>2012-05-06T18:30:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10641">
    <title>Re: How to debug gapless issues?</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10641</link>
    <description>&lt;pre&gt;I never was a friend of album art, so, yes, its only the files.

Where exactly does the logf output go to and how do I enable it? I
grepped for logf definitions, but I was rather confused by the hits.

I tried that some time ago and its still up at 10min.

I cleared the settings when I reinstalled rockbox after putting in the SSD.

Well, I was watching the buffering thread debugscreen once more and
found that the pcm buffer starves on track change. Is that the intended
behaviour, but without the wait for refill or should it never starve on
(expected) track change at all? If so, that would be a hint I guess.

cheers

&lt;/pre&gt;</description>
    <dc:creator>Jonas Wielicki</dc:creator>
    <dc:date>2012-05-06T17:23:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10640">
    <title>Re: How to debug gapless issues?</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10640</link>
    <description>&lt;pre&gt;

&amp;lt;...&amp;gt;


And you just copied the files over, not adding (big) album art or something like 
that?


One way could be to enable logf in buffering and perhaps playback. If you add
the current tick to the log line, you should be able to zero in on any delays.

Have you tried increasing the anti-skip buffer? That should tell if it is
related to "spin up".

And you have tried clearing all settings too, I hope. That has a tendency to fix
strange problems... :)

&lt;/pre&gt;</description>
    <dc:creator>Magnus Holmgren</dc:creator>
    <dc:date>2012-05-06T16:51:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10639">
    <title>How to debug gapless issues?</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10639</link>
    <description>&lt;pre&gt;Hi folks,

I am still struggling with a gapless (or not) playback issue I'm having
since I got the SSD in my player.

As this is nonstandard hardware, I guess its best when I track the bug
by myself, but I need some advice where to look for potential issues.

My first thought was that it might be due to the SSD being slow when
writing changes to the playlist control file. So I tried to disable all
writing by putting a return 0 right at the start of flush_cached_control
in playlist.c, but that did not fix the issue.

It should be no problem in buffering, as the buffers are pretty full in
the buffering thread debug screen. The songs are all ogg/vorbis, so it
should not be an codec issue; also, everything was fine before the SSD
upgrade.

When turning on Crossfade, after an reboot, crossfading works, but it
feels as if there is a lag between the start of crossfade and the press
of the next button on manual skip. Crossfading works then though. On
end-of-track skipping, there is still a lag and no crossfading (although
I set it to be on Always).

I based my work on the v3.11 branch, however, I could not find any
relevant bugs in the bugtracker for this version which would explain
that behaviour.

So basically I'm looking for pointers on where to look for potential
gap-causers or in general means to debug this problem. Any suggestions?

In the meantime, I also implemented support for the CHECK POWER MODE ata
command which may have fixed another issue but did not help on this one.
Do we have any support for hinting the ATA thread that a read/write is
going to occur in the next few seconds or milliseconds so that it can
spin up the drive in advance? Although I thought that rockbox should not
have an issue with the playlist app blocking on a file write when it
comes to playback (threading for the win!).

To summarize the questions:
(1) What are common gap introducers I might've regressed into?
(2) If its not that, where could gaps be introduced if the hard drive
causes lag?
(3) Are there means to properly debug the device?

best regards
Jonas

ps.: for those who did not follow my previous thread, I am using an
iriver h320 with an SSD.

&lt;/pre&gt;</description>
    <dc:creator>Jonas Wielicki</dc:creator>
    <dc:date>2012-05-06T16:21:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10638">
    <title>Re: Ladies and gentlemen, we have sound on the Creative Zen X-Fi3!</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10638</link>
    <description>&lt;pre&gt;
It's getting boring. Every couple of days new "gentlemen" mail! :-)))

&lt;/pre&gt;</description>
    <dc:creator>Al Le</dc:creator>
    <dc:date>2012-05-01T09:42:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10637">
    <title>Treten Sie meinem Netzwerk auf LinkedIn bei</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10637</link>
    <description>&lt;pre&gt;LinkedIn
------------




    Jacob Mansfield möchte Sie als Kontakt auf LinkedIn hinzufügen:
  

------------------------------------------

Ich möchte Sie gerne zu meinem beruflichen Netzwerk auf LinkedIn hinzufügen.

Einladung von Jacob Mansfield annehmen
http://www.linkedin.com/e/-10baj0-h1opd4dh-2w/usr0uRhcvkZDWCRmYFo5YYCfQXVDxmR8WU-sDU/blk/I145919248_150/6lColZJrmZznQNdhjRQnOpBtn9QfmhBt71BoSd1p65Lr6lOfP0RclYUd38VcjARd359bRxge6xMgAtLbPwTdzkUcPsMejoLrCBxbOYWrSlI/EML_comm_afe/?hs=false&amp;amp;tok=0Nj4jpTaUAKBc1

Einladung von Jacob Mansfield anzeigen
http://www.linkedin.com/e/-10baj0-h1opd4dh-2w/usr0uRhcvkZDWCRmYFo5YYCfQXVDxmR8WU-sDU/blk/I145919248_150/c3kNnPwQczANejkQckALqnpPbOYWrSlI/svi/?hs=false&amp;amp;tok=1p--3LF5EAKBc1

------------------------------------------

Warum sollten Sie Jacob Mansfield in Ihr Netzwerk einladen?

Die Kontakte von Jacob Mansfield könnten auch Ihnen nützlich sein:

Nachdem Sie die Einladung von Jacob Mansfield akzeptiert haben, sehen Sie nach, welche Kontakte von Jacob Mansfield Sie eventuell auch kennen und wem Sie vorgestellt werden möchten. Durch diese neuen Kontakte können sich später neue Gelegenheiten ergeben.
 
&lt;/pre&gt;</description>
    <dc:creator>Jacob Mansfield über LinkedIn</dc:creator>
    <dc:date>2012-05-01T08:36:02</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10636">
    <title>Ladies and gentlemen, we have sound on the Creative Zen X-Fi3!</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10636</link>
    <description>&lt;pre&gt;I'm pleased to announced that my Creative Zen X-Fi3 successfully played its
first song:
Vincent Cheng - Seasons (Creative Demo)

Hopefully this target is pretty stable, everything basically works except
the recording, speakers, tv encoding and bluetooth of course.

Cheers !

Amaury Pouly
&lt;/pre&gt;</description>
    <dc:creator>Amaury Pouly</dc:creator>
    <dc:date>2012-04-30T17:41:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10635">
    <title>Re: DevConEuro 2012</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10635</link>
    <description>&lt;pre&gt;2012/4/27 Frank Gevaerts &amp;lt;frank&amp;lt; at &amp;gt;gevaerts.be&amp;gt;:

Is anyone interested in room sharing in Ibis?

MB

&lt;/pre&gt;</description>
    <dc:creator>Marcin Bukat</dc:creator>
    <dc:date>2012-04-27T11:32:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10634">
    <title>DevConEuro 2012</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10634</link>
    <description>&lt;pre&gt;Hello once more,

DevConEuro 2012 is only three weeks away now. If you plan to attend,
and you haven't done so already, please add your name to the list on
http://www.rockbox.org/wiki/DevConEuro2012.

If you're still looking for a place to stay and need some ideas,
http://www.ibishotel.com/gb/hotel-1456-ibis-hasselt-centrum/index.shtml
is a popular option, with several people already having booked there.
Note that the price currently advertised there for the devcon weekend
is only valid if you book at least 20 days in advance, so it will likely
go up in the next few days. 

Frank

&lt;/pre&gt;</description>
    <dc:creator>Frank Gevaerts</dc:creator>
    <dc:date>2012-04-27T11:28:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10633">
    <title>Re: Ladies and gentlemen, we have sound on the Creative Zen X-Fi2!</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10633</link>
    <description>&lt;pre&gt;
Great work!

&lt;/pre&gt;</description>
    <dc:creator>Björn Stenberg</dc:creator>
    <dc:date>2012-04-27T10:45:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10632">
    <title>Ladies and gentlemen, we have sound on the Creative Zen X-Fi2!</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10632</link>
    <description>&lt;pre&gt;I'm pleased to announced that my Creative Zen X-Fi2 successfully played its
first song:
2Pac - California Love

The port is still very unstable, experimenting random crashes and weirdness
and is still running out of the SD card because of the lack of NAND drive.
On the good side it is very close to the Creative Zen X-Fi3 which also runs
rockbox (without sound unfortunately) so both ports share a lot of code and
will hopefully bring more features to the imx233/ subtarget.

Cheers !

Amaury Pouly
&lt;/pre&gt;</description>
    <dc:creator>Amaury Pouly</dc:creator>
    <dc:date>2012-04-25T17:49:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10631">
    <title>Re: Fixing lags/freezes with SSD in iriver H320 (updates)</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10631</link>
    <description>&lt;pre&gt;I managed to fix the most prevalent issues with the changeset:
&amp;lt;http://gerrit.rockbox.org/r/218&amp;gt;

However, I just observed a panic which may be related to the oddity I
pointed out in my previous mail:


I got a *PANIC* with flush_fat_sector() - Could not write sector 40883
(error -5) in the middle of playback, which indicates that a read/write
timed out.

I am currently waiting for a build to see whether a larger
READWRITE_TIMEOUT helps here. If so, I would suggest to change the code
to wait a shorter time in the first run and to wait only on the second
run the full 30 seconds after a transfer has been started. This would
mitigiate possible lags. However, I'm not deep enough in the ATA matter
to see whether that actually makes sense.
Can someone give me a hint here?

best regards,
Jonas

&lt;/pre&gt;</description>
    <dc:creator>Jonas Wielicki</dc:creator>
    <dc:date>2012-04-17T17:22:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10630">
    <title>Re: re FS#12625 - Sleep timer setting is broken</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10630</link>
    <description>&lt;pre&gt;Am 17.04.2012 09:34, schrieb Nick Peskett:

The shortcuts menu can replace the quickscreen these days. Perhaps 
that's more appropriate.

Best regards.

&lt;/pre&gt;</description>
    <dc:creator>Thomas Martitz</dc:creator>
    <dc:date>2012-04-17T08:04:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10629">
    <title>Re: re FS#12625 - Sleep timer setting is broken</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10629</link>
    <description>&lt;pre&gt;
Ah, I hadn't realised it was the dynamic menu title that was preventing 
it from being added to the quick screen.


Could you submit it to Gerrit? I'd be interested to have a look.

I'm sure there'll be people who would prefer this trade-off too.

Cheers

Nick

&lt;/pre&gt;</description>
    <dc:creator>Nick Peskett</dc:creator>
    <dc:date>2012-04-17T07:34:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10628">
    <title>Re: re FS#12625 - Sleep timer setting is broken</title>
    <link>http://permalink.gmane.org/gmane.comp.systems.archos.rockbox.devel/10628</link>
    <description>&lt;pre&gt;
first I liked your idea to integrate the sleeptimer and cancel and show
the "time left" into one menu line.
Only later I saw you cant add this function to the quick screen.
And using a %bs in wps is far easier to get the information how long
until sleep.

Since I do switch between sleep timer on/off quite often - its not nice
to go through menus every time.

So I reverted the sleeptimer duration to an int menu and added a menu
point "Run Sleep Timer" (bool),
which starts/stops the timer duration and resets it - if started, and
runs the the StartOnBootTimer if enabled....
Now you can easily add every single item to the quickmenu screen - which
gives the user more flexibility.

I would supply a patch if anybody is interested.


Cheers

Richard


&lt;/pre&gt;</description>
    <dc:creator>Richard Fröhning</dc:creator>
    <dc:date>2012-04-16T11:32:35</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.systems.archos.rockbox.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.systems.archos.rockbox.devel</link>
  </textinput>
</rdf:RDF>

