| 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:00 |
| 01:31:31 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:31:32 | *** | No seen item changed, no save performed. |
| 04:00 |
| 04:34:16 | | Join IPG [0] (~InvoxiPla@176.25.14.149) |
| 05:00 |
| 05:31:35 | *** | No seen item changed, no save performed. |
| 06:00 |
| 06:57:07 | | Quit IPG (Read error: Connection reset by peer) |
| 07:00 |
| 07:31:39 | *** | Saving seen data "./dancer.seen" |
| 07:59:20 | | Quit PheralSparky (Quit: Leaving) |
| 08:00 |
| 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:00 |
| 09:31:43 | *** | Saving seen data "./dancer.seen" |
| 10:00 |
| 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 |
| 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:00 |
| 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:00 |
| 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:00 |
| 14:08:00 | | Quit hactar|ant (Quit: and it's always been the same / it's just a complicated game) |
| 15:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 18:55:16 | | Join massiveH [0] (~massiveH@2600:4040:a982:c800:1c4c:668b:a80e:7875) |
| 19:00 |
| 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:00 |
| 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:00 |
| 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:00 |
| 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) |
icon identifies that the person is a core developer (has commit access).