--- Log for 26.12.123  Server: lead.libera.chat  Channel: #rockbox
--- Nick: rb-logbot  Version: Dancer V4.16  Started: 1 month and 8 days ago

00.33.42 #       <tm512`> speachy: so wait, with a regular CF card, does that also trigger rockbox to never use power management features for the storage, if it can't distinguish between a real CF and an SD adapter claiming to be CF?
00.34.59 #       <tm512`> if so, I guess I'm making my own patched builds as long as that behavior is easily patched out
00.35.48 Nick    tm512` is now known as tm512 (~tm512@user/tm512)
00.46.24 Quit    massiveH (Quit: Leaving)
01.31.31 ***     Saving seen data "./dancer.seen"
03.31.32 ***     No seen item changed, no save performed.
04.34.16 Join    IPG [0] (~InvoxiPla@176.25.14.149)
05.31.35 ***     No seen item changed, no save performed.
06.57.07 Quit    IPG (Read error: Connection reset by peer)
07.31.39 ***     Saving seen data "./dancer.seen"
07.59.20 Quit    PheralSparky (Quit: Leaving)
08.06.30 Quit    CH23_M (Ping timeout: 260 seconds)
08.08.43 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
08.13.58 Quit    paulk (Ping timeout: 260 seconds)
08.14.16 Join    paulk [0] (~paulk@vpn-0-22.aquilenet.fr)
08.40.29 Quit    braewoods (Read error: Connection reset by peer)
08.40.56 Join    braewoods [0] (~braewoods@user/braewoods)
08.47.06 Join    IPG [0] (~InvoxiPla@176.25.14.149)
08.54.27 Quit    braewoods (Remote host closed the connection)
08.54.43 Join    braewoods [0] (~braewoods@user/braewoods)
09.31.43 ***     Saving seen data "./dancer.seen"
10.18.46 Join    Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net)
10.51.04 #       <_bilgus_> CF cards should work with power management not familiar with the different modes but for sure there is one that emulates ATA 
10.54.13 #       <_bilgus_> so the above patch fixes the db duplicate issue, this arose since we no longer hid the mounted drive and the reason for that is the removal of /<microsd1> as a valid path causes issues when you generate a playlist running from the SD card and later try to play it from a build running on the internal memory
10.54.27 Quit    braewoods (Remote host closed the connection)
10.57.02 #       <_bilgus_> we try ignoring the path prefix but that doesn't help either since its not enumerated into the root anymore /<microSD1>/Foo isn't available at /Foo and likely my current patch doesn't fix this
10.58.33 #       <_bilgus_> probably I need to switch that logic to ignore the enumerated paths such as /Foo in favor of /<MicroSd1>/Foo 
11.00.48 #       <_bilgus_> issue is that it will take more logic so better might be to ignore all redirects in the db scanning or maybe introduce some logic to build a list of scan targets when the scanning path is root
11.01.16 #       <jssfr> hm, my sansa reported some playlist file error. i restarted it and then it stuck at "loading..." and then "playlist buffer full"
11.01.22 #       <jssfr> is this the flash dying?
11.01.34 #       <_bilgus_> possible
11.01.55 #       <_bilgus_> playlist buffer full sounds like the settings got wiped out
11.02.21 #       <jssfr> with default settings, rockbox doesn't immediately start playback after power on, does it?
11.02.45 #       <_bilgus_> shouldn't
11.02.49 #       <_bilgus_> if you crashed after changing settings its possible they didn't get written
11.02.50 #       <jssfr> now it shows "error accessing playlist file" on top of "playlist buffer full"
11.03.08 #       <jssfr> but it's not reactive to input (except that the display turns on when I press a button)
11.03.34 #       <_bilgus_> probably stuck trying to read something corrupted
11.03.48 #       <_bilgus_> that sounds like the start of flash dying
11.04.04 #       <jssfr> :(
11.04.15 #       <_bilgus_> bad sectors causing corruption
11.04.44 #       <jssfr> is there a way to make it work off the SD card for all things mutable?
11.04.56 #       <jssfr> meanwhile, I guess this is a good time to switch to my spare
11.04.57 #       <_bilgus_> get the multiboot loader on there if it fails during we have some low level ways to get a bootloader on it assuming it hasn't gone read only
11.05.19 #       <_bilgus_> johnb used his for years like that
11.05.43 #       <jssfr> that does sound like something I could try
11.05.49 #       <jssfr> is there documentation for that somewhere?
11.06.01 #       <_bilgus_> are you clipzip or Plus?
11.06.05 #       <jssfr> excellent question
11.06.21 #       <jssfr> this seems to be a clip zip
11.06.31 #       <jssfr> (going by the pictures on https://www.rockbox.org/manual.shtml )
11.06.34 #       <_bilgus_> zip has big button pad plus is monochrome with smaller button pad
11.06.44 #       <jssfr> the "back" button gives it away
11.06.45 #       <_bilgus_> zip is color
11.07.02 #       <jssfr> yep, color display + back button
11.07.43 Join    braewoods [0] (~braewoods@user/braewoods)
11.11.10 #       <_bilgus_> so I have the lates bootloader here if you want http://www.mediafire.com/file/2zaz1468suj7drc/ClipZipMultiBoot2023_clpza.zip
11.11.20 #       <jssfr> I'll also take build instructions :)
11.11.46 #       <_bilgus_> I just built this with our latest patches Ive tested it on a clipZip and it works
11.12.17 #       <jssfr> alright, extracted, what do I do with that .bin?
11.12.20 #       <_bilgus_> just unzip to the root of internal and boot the device into the sansa fw (vol up at power on I think)
11.12.34 #       <_bilgus_> might be vol dn
11.12.42 #       <jssfr> I'm already in the sansa FW --- rockbox panic'd when trying to USB
11.12.50 #       <jssfr> ("probably not a great sign")
11.12.54 #       <_bilgus_> it should boot say upgrading then power off in 10 mins ish
11.12.56 #       <jssfr> (it was "left" ftr)
11.12.59 #       <jssfr> ack
11.13.40 #       <_bilgus_> this is the scary part if it doesn;'t shut off leave it on
11.13.55 #       <_bilgus_> we need the connection if it failed so we can fix it
11.14.09 #       <jssfr> "Aktuali. im Gange"
11.14.16 #       <jssfr> (TIL that device had the OF set to german)
11.14.35 #       <jssfr> it seems done?
11.14.47 #       <_bilgus_> did it turn off?
11.14.50 #       <jssfr> it did
11.15.14 #       <_bilgus_> ok so you should be good to boot from sd unzip a .rockbox to the root
11.15.22 #       <_bilgus_> of the sd 
11.16.03 #       <_bilgus_> thn a file called rockbox_main.clipzip either totally empty (touch in linux) or a single / no return 
11.16.19 #       <jssfr> copying...
11.16.34 #       <_bilgus_> the single '/' is easier it seems editors like to add a CR
11.17.12 #       <jssfr> that `rockbox_main.clipzip`, into .rockbox or into the root of the SD card?
11.17.19 #       <_bilgus_> root of sd
11.17.29 #       <_bilgus_> same level as the .rockbox dir
11.17.37 #       <jssfr> thanks
11.17.44 #       <jssfr> done, plugged SD card in, stuck at Loading…
11.17.49 #       <_bilgus_> you can also boot from fw in different folders but beyond our scope
11.17.50 #       <jssfr> Playlist Buffer Full again
11.17.57 #       <jssfr> makes me think that didn't work
11.18.16 #       <_bilgus_> check debug menu under boot data
11.18.20 #       <jssfr> I can't
11.18.28 #       <jssfr> or I don't know how
11.18.39 #       <_bilgus_> main menu scroll to syatem
11.18.42 #       <jssfr> I cannot seem to break out of the "Loading" / "Playlist Buffer Full" state, except by hard reset.
11.18.43 #       <_bilgus_> system
11.19.00 #       <_bilgus_> sounds like still booting the internal
11.19.04 #       <jssfr> yeah
11.19.12 #       <jssfr> even pressing stop right after boot (which normally aborts loading the playlist) doesn't do anything.
11.19.37 #       <jssfr> I'll try to see if I can read the bootloader version number
11.19.48 #       <jssfr> something 41... I think
11.22.03 #       <jssfr> https://paste.debian.net/hidden/657e5d17/
11.22.09 #       <jssfr> does that look right (listing of the sd card root from linux)
11.22.15 #       <_bilgus_> yep thats right ok so .rockbox directory on the sd and you rockbox_main.clipzip has a single /?
11.22.31 #       <_bilgus_> sorry previous thats right the ID on bootloader
11.22.31 #       <jssfr> it's zero bytes, just touch'd
11.22.35 #       <jssfr> ack
11.23.25 #       <_bilgus_> yes that looks right oo
11.23.27 #       <_bilgus_> too
11.23.35 #       <_bilgus_> you are using a dev version?
11.24.09 #       <jssfr> I pulled the latest 3.15 from the website just now to avoid any brokenness from my build
11.24.14 #       <_bilgus_> nope
11.24.27 #       <_bilgus_> multiboot was added the month after
11.24.30 #       <jssfr> oha
11.24.33 #       <jssfr> so I need a dev build?
11.24.45 #       <jssfr> on the SD card, or also on the internal storage?
11.24.54 #       <_bilgus_> just the SD
11.24.59 #       <jssfr> ack
11.25.18 #       <_bilgus_> I actually leave 3.15 on my internal just to see how bad it is
11.25.28 #       <_bilgus_> and a way to recover
11.25.38 #       <jssfr> copying ...
11.26.10 #       <jssfr> oha!
11.26.16 #       <jssfr> that looks like a fresh clean rockbox
11.26.20 #       <jssfr> thank you veeeery much <3
11.26.23 #       <_bilgus_> so in the debug menu this new bootloader should show volume <1> as your boot volume
11.26.36 #       <jssfr> it does
11.26.58 #       <jssfr> so I'll try to salvage my settings and then I'm good to go
11.26.59 #       <_bilgus_> you can still read stuff from internal if you want but try not to add new files
11.28.03 #       <jssfr> great!
11.28.35 #       <jssfr> _bilgus_, you genuninely made my day just now.
11.28.46 #       <_bilgus_> should be able to copy the old settings but things have chnaged so if you have weird issues start with a clean setting file and do it through the menus
11.29.05 #       <_bilgus_> good another sansa saved :)
11.29.07 #       <jssfr> seems to have worked, if I notice anything weird I'll try to start from scratch
11.29.36 #       <jssfr> I should probably do that to my spare clip+ too.
11.29.42 #       <_bilgus_> yes
11.30.04 #       <jssfr> actually, that may make it necessary to have multiple firmware dirs
11.30.12 #       <jssfr> given that I use the same SD card :-)
11.30.21 #       <_bilgus_> and that works must be this years dev version though
11.30.31 #       <jssfr> but AIUI, I just put the path to the boot root into the rockbox_main.$devtype, making sure there's no whitespace or whatever in it
11.30.50 #       <_bilgus_> so fo that create a clipzip and clip+ rockbox_main
11.31.01 #       <_bilgus_> and put each fw in their own dir
11.31.25 #       <_bilgus_> in the redirect file its just (fw in /cz and cp) /cp and /cz
11.31.44 ***     Saving seen data "./dancer.seen"
11.32.03 #       <_bilgus_> then when you boot they will each have their own root the clipzip has /cz and the plus will have /cp
11.33.04 #       <jssfr> righty
11.33.29 #       <jssfr> I'll have to look where to find a current bootloader for the clip+, but first I need to get the dough started--that's what I was grabbing the clipzip for, initially :)
11.34.00 #       <_bilgus_> I actually have one of thiose laying around too
11.34.26 #       <jssfr> .. it seems like this firmware lists the internal storage as <microSD0>?
11.34.29 #       <jssfr> is that expected?
11.35.00 #       <jssfr> uuuh and great, the weird flickery playback progress bar is gone.
11.35.52 #       <_bilgus_> https://www.mediafire.com/file/iwz10j7z5fib7fa/ClipPlusMultiBoot2023_clppa.zip/file
11.36.12 #       <_bilgus_> I haven't tried that one yet but I built them at the same time
11.36.38 #       <jssfr> thanks, downloaded. installation procedure is the same as on the clipzip?
11.36.42 #       <_bilgus_> yep <MicroSd0> is internal and <MicroSd1> is your card
11.36.48 #       <_bilgus_> yep same steps
11.36.58 #       <_bilgus_> again if it doesn't turn off leave it on
11.39.04 #       <_bilgus_> we actually have a virtual root now where the drives get enumerated and we use that root directory (rockbox_main) as the root of the file browser
11.39.42 #       <_bilgus_> drives can be hidden I eventually plan to allow it without recompiling
11.40.23 #       <_bilgus_> ATM I'm still dealing with some fallout from the database but that will be fixed before 2024 I hope
11.41.12 #       <_bilgus_> (it scans both / and /mircosd1 causing duplicate entries
11.41.15 #       <_bilgus_> )
12.17.05 Join    chris_s [0] (~chris_s@2a02:908:1e0:9ba0::ddab)
12.22.56 Quit    chris_s ()
12.55.45 Quit    IPG (Read error: Connection reset by peer)
13.07.13 Quit    CH23_M (Ping timeout: 276 seconds)
13.11.25 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
13.31.46 ***     Saving seen data "./dancer.seen"
14.08.00 Quit    hactar|ant (Quit: and it's always been the same / it's just a complicated game)
15.00.47 Quit    CH23_M (Read error: Connection reset by peer)
15.01.08 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
15.31.50 ***     Saving seen data "./dancer.seen"
16.21.21 Join    LanMarc77 [0] (~marcel@185.89.38.134)
16.22.03 #       <LanMarc77> Hi greetings everyone, is the forums user saratoga here?
16.34.08 Join    Saratoga [0] (~Saratoga@172.56.91.149)
16.34.54 #       <LanMarc77> Hi Saratoga
16.34.57 #       <Saratoga> LanMarc77: I don't have much time to talk now, but I do check the logs so you can ask things here and if anyone knows the answer they'll usually get back to you eventually
16.35.14 #       <LanMarc77> Ah ok.
16.35.56 Quit    Saratoga (Client Quit)
16.37.33 #       <LanMarc77> Following my posts on my bricked stmp3770 device I already tried getting a fitting .sb to reenable the mass storage mode with sbloader but was not successfull
16.38.26 #       <LanMarc77> I tried extracting hostlink.sb from a create zen firmware as I understood this is what I need for an stmp3770, older models seemed to use usbmsc.sb
16.40.53 #       <LanMarc77> but then I am not sure if I did the right thing as I only had a firmware.sb, extracted it with sbtoelf and then tried to extract what I think is the right .elf back to an .sb
16.42.13 #       <LanMarc77> Still I do not know if this direction is even correct, I could not find an .sb for an stmp3770 in specific only for older models like the stmp35xx or stmp36xx or the newer stmp3780
16.52.57 #       <LanMarc77> I also tested the recovery from the Sansa Players, but my Playaway is not detect by the driver of their package as the .inf also does not contain the vid/pid combination of the Playaway but only from older models of the stmp
17.01.10 Quit    LanMarc77 (Quit: Konversation terminated!)
17.19.00 Quit    Trzyzet (Read error: Connection reset by peer)
17.20.23 Join    Trzyzet [0] (~Trzyzet@cpc110919-live30-2-0-cust650.17-2.cable.virginm.net)
17.31.53 ***     Saving seen data "./dancer.seen"
18.55.16 Join    massiveH [0] (~massiveH@2600:4040:a982:c800:1c4c:668b:a80e:7875)
19.31.54 ***     No seen item changed, no save performed.
19.50.51 #       <Raptorious> _bilgus_: how does one go about hiding the "internal" drive when booting from sdcard?
21.31.58 ***     No seen item changed, no save performed.
21.43.04 Quit    braewoods (Remote host closed the connection)
21.54.05 Join    braewoods [0] (~braewoods@user/braewoods)
22.07.25 Join    PheralSparky [0] (~Shawn@user/shawn/x-4432647)
22.08.43 Join    dconrad [0] (~dconrad@152.117.104.216)
22.09.52 #       <dconrad> So between g#5495 and g#5503, is there a strong preference? I've been using the latter for almost the last month with no issues, so it seems to work as intended
22.10.14 #       <dconrad> hmm, no gerrit bot?
22.10.35 #       <dconrad> https://gerrit.rockbox.org/r/c/rockbox/+/5495
22.10.42 #       <dconrad> https://gerrit.rockbox.org/r/c/rockbox/+/5503
22.11.21 #       <dconrad> ErosQ support for i2c dac, including discovery/fallback to software volume
22.12.32 #       <dconrad> There's also 5530 (https://gerrit.rockbox.org/r/c/rockbox/+/5530), but I still need to get around to trying to make the menus self-hide in swvol mode
22.12.52 #       <dconrad> (digital filters)
22.24.41 Quit    massiveH (Quit: Leaving)
23.22.24 Quit    dconrad (Remote host closed the connection)
23.23.54 Join    dconrad [0] (~dconrad@152.117.104.216)
23.28.40 Quit    dconrad (Ping timeout: 255 seconds)
23.29.08 Join    dconrad [0] (~dconrad@152.117.104.216)
23.32.02 ***     Saving seen data "./dancer.seen"
23.37.06 Join    jacobk [0] (~quassel@47-186-95-57.dlls.tx.frontiernet.net)