Click in the nick column to highlight everything a person has said.
The icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

Zagor: (for the logs) it seems safari hates the live log. archived logs work fine but the live log tries to download the file using the download manager and gets stuck in a loop. if a user talks while i leave the download running, it will update the log that is being saved. supposedly the server push feature does work in safari though...

01:48:51

Nick webguest25is now known as midgey|web (n=8dd3f85c@gateway/web/cgi-irc/labb.contactor.se/x-f2ad0d1faa6a6787)

(for the logs) Before the power management changes for PP-targets were allowed to be submitted, I had to make a change -> still let the Dock connector pin17 be powered via the PCF power controller (iPods only). I've made some tests and found out that this single voltage supply will need 1.5mA and will therefor decrease the runtime a lot (e.g. on 60/80GB 5G: roundabout -45min).

(for the logs) For iPod Videos / nanos there is a GPIO-input which detects "dock connected (yes/no)" in the debug_menu. I'll try to use this for Video/nano to enable/disable the dock connector pin in a proof-of-concept.

martii: Specifically to the ipod accessory protocol issue, you could start by trying to gather all known information in a wiki page, finding the specific pieces of source code from the IPL kernel that deal with the serial port on the 3G etc, finding hardware tools (such as dock adaptors) that could help someone develop the drivers.

oh hey linuxstb... maybe you can help. I tried to compile tcctool with the VMWare debian u have up on the site, but it wont compile cause the image up on the site doesnt have libusb-dev installed... and when I apt-get it, it tells me I need to rebuild the kernel... which I hope isnt necessary :P

Slasheri: hi. :) regarding fs#8599, do you think it is better to a) introduce an additional 'valid' flag in mp3entry, b) store index+1 in mp3entry.tagcache_idx and still use 0 to mean "invalid" or c) use -1 as a flag for invalid

Slasheri: c) has the big disdvantage that mp3entry structures are created all over the place and typically initialised with memset(0), so it is difficult to make sure that tagcache_idx is set to -1 initially

jhMikeS, linuxstb : there is actually even more stuff still running in ISR-context: usb_core_control_request() runs from the interrupt handler. I've actually been wondering if that might be one of the causes for the problems I've been having while trying to rework some stuff

Horscht: I would guess in the appropriate firmware/export/config-*.h file. I put -DUSE_ROCKBOX_USB in my Makefile on the EXTRA_DEFINES line (so that line now reads "export EXTRA_DEFINES=-DUSE_ROCKBOX_USB")

I had a productive lunch break. As a result, I could transfer 2GB from my sansa to the host (using dd) without resets (although there were some during enumeration and partition scanning). Speed was 471 kB/s

It was even weirder in that when I unplugged it, it went dead on me, but that seems to have been another incident I've been having of the battery needing to be removed and reseated. It just happened to occur at the moment I unplugged it. Freaked me out.

major_works: About your last point (still booting the OF when plugging in) : changing that requires building the bootloader using -DUSE_ROCKBOX_USB, and then updating it. I wouldn't recommend doing that until you can actually really use this stuff

OK, thanks for that tip. I'll wait before taking that plunge. I'll also give connecting another try later this morning and let you know if it behaves any differently. Thanks also for your hard work on this... it's appreciated.

Well, well, well... looks like you was right. I didn't wait long enough. Two drives now show up in Explorer. It took almost 10 minutes. However, Explorer seems to have hung up trying to open the Sansa.

linuxstb: true. I just tried moving set_serial_descriptor() to usb_core_control_request_handler(). That doesn't crash anymore, but the serial number doesn't match what the OF gives me (OF gives 4453033f-32305453-b9108047-6b008c55-00000000, RB gives 00000000-00000000-9405B487-401DFA13-00000000)

linuxstb: I moved the serial number reading to the start of usb_core_thread(). Since control requests are now also dispatched through this thread that is guaranteed to be early enough. usb_core_init() is still called in interrupt context, but it now does nearly only memory stuff.

While it might be understandable due to the nature of Rockbox, this is not an iPod support channel - nor is it an iTunes-Replacement channel. This is a channel about one specific piece of software which does not even run on your iPod Shuffle.

Since it appears that the serial number on the C200 is not on the as3514, it must be somewhere else. system-pp502x.c seems to suggest that there is an on-cpu rom. Is that mapped somewhere in the address space ?

rasher: can you test transfer_descriptors.diff and threading.diff separately ? serial.diff is linuxstb's sansa serial number patch, shuffled around to make it not crash. Testing that would be useful as well, but less important right now

Domonoky_: bluebrother: any idea how the xml file for the config settings should look like? I had a bit of a play to get it written by a script last night but failed miserably so might just convert settings_listc by hand

perrikwp, bertrik: Can you try marking the .rockbox directory hidden (only the directory itself, not the contents) ? I have a suspicion that windows scans subdirectories to help it decide what icon to show, which is not a good idea on anything but a high speed device. Of course, that will probably only help if you didn't ask to see hidden directories

advlaptop2019: if you are already running a usb-enabled build I'd welcome some test results, but if not it's not probably not really worth it just for testing this issue. Note that although I have very few or no problems with the usb build, I still heavily recommend backups...

bertrik: that's 200k/second. I'm seeing slightly over 400k/s on linux, but you might have had one of our infamous resets (those take 30 seconds on linux, windows probably also does something similar but I don't know their timeout)

perrikwp: on my sansa, .rockbox has 377 files and directories. That's more than the number of audio files you removed. I suspect the problem is more the number of files than the actual size, so this would still be significant.