| 00:00:14 | | Join knittl [0] (n=knittl@193.170.133.61) |
| 00:00:42 | | Quit DavidS1 (Read error: 110 (Connection timed out)) |
| 00:02:46 | | Join CyBergRind|w [0] (n=cbr@212.98.160.130) |
| 00:02:59 | kugel | linuxstb: I begin to see |
| 00:03:44 | jhMikeS | Nico_P: have you been able to into the buffer screen and skip backward to force full rebuffers and observed anything interesting? |
| 00:04:04 | Nico_P | I'll try |
| 00:04:45 | preglow | amiconn: i can't remember anything about that being a problem |
| 00:06:14 | amiconn | preglow: Codec buffer and plugin buffer are at the end of ram now, which is a different address depending on whether there are 32 or 64MB ... |
| 00:06:30 | Nico_P | jhMikeS: I don't see much apart from what I said above about buffering and metadata competing over the disk |
| 00:06:45 | preglow | amiconn: and moving them to the start of ram is the straightforward solution |
| 00:06:49 | preglow | startish, at least |
| 00:07:04 | amiconn | I made a suggestion on how sections could be re-ordered at devcon 2007, but nobody actually implemented it |
| 00:07:10 | | Quit simonrvn ("bbl") |
| 00:07:13 | preglow | yes, i remember that |
| 00:07:15 | preglow | which is why i asked |
| 00:07:16 | Nico_P | jhMikeS: do you think it would be wiser to interleave metdata and audio loading? |
| 00:07:34 | amiconn | So I think that nobody is interested enough to actually do it |
| 00:07:51 | Nico_P | amiconn: is it a lot of work? |
| 00:07:53 | preglow | amiconn: would mostly just be linked script hacking, yes? |
| 00:07:55 | jhMikeS | Nico_P: I was considering the idea of having the buffering thread actually do the parsing if that's what you mean |
| 00:07:57 | preglow | linker |
| 00:08:24 | amiconn | preglow: Not only. It also requires work in crt0 (relocating stuff after starting |
| 00:08:47 | preglow | jhMikeS: i'm starting to think about doing some work towards supporting proper multiple sample rates... |
| 00:08:53 | Bagder | the linker script should be easier to fiddle with now when moved into the target tree and thus less ifdefy |
| 00:08:58 | amiconn | The image will be loaded at the start of ram, and an artifical gap in the file would be bad |
| 00:09:00 | preglow | Bagder: definitely |
| 00:09:27 | amiconn | Bagder: If we do this reshuffle, we should probably do it for all targets |
| 00:10:02 | amiconn | Could be useful to get rid of the special 8MB archos builds, and perhaps also merge iriver h100 and h120 builds |
| 00:10:06 | | Join crwll [0] (n=crawlie@a88-114-143-95.elisa-laajakaista.fi) |
| 00:10:19 | Nico_P | jhMikeS: that could help, yes. we could make it load metadata with priority over audio |
| 00:10:21 | DerPapst | adn ipv |
| 00:10:26 | DerPapst | doh |
| 00:10:32 | jhMikeS | preglow: I'm having nightmares about that |
| 00:10:36 | DerPapst | and ipod video 32MB and 6MB |
| 00:10:43 | DerPapst | *64MB |
| 00:10:43 | preglow | jhMikeS: yeah, i probably haven't thought well enough about it... |
| 00:10:51 | preglow | but still, i see no _real_ reason it should be exceedingly hard |
| 00:10:59 | amiconn | DerPapst: No need to mention the original reason... |
| 00:11:29 | DerPapst | sorry? ;-) |
| 00:11:35 | jhMikeS | Nico_P: isn't the buffer arranged as |MD|AUDIO|MD|AUDIO|? |
| 00:12:02 | jhMikeS | The codec won't start anyway until the metadata is loaded |
| 00:12:22 | Nico_P | jhMikeS: it is, yes. but once the spaces are allocated there's no real constraint on the order with which we fill them |
| 00:12:32 | | Quit bluebrother ("sleep. now.") |
| 00:12:37 | | Quit Ave (Read error: 101 (Network is unreachable)) |
| 00:12:40 | | Quit crwl (Read error: 101 (Network is unreachable)) |
| 00:12:45 | | Join Ave [0] (i=ave@a91-152-238-56.elisa-laajakaista.fi) |
| 00:12:50 | amiconn | The iriver h100+h120 unification would need a bit of runtime behaviour modification (spdif enable polarity), but other builds do that too (archos, ipod 1st/2nd Gen....) in other areas |
| 00:13:04 | jhMikeS | which explains the variation in how long it may take a file to start playing |
| 00:13:06 | preglow | amiconn: such a small runtime check is perfectly ok, if you ask me |
| 00:13:07 | Nico_P | so I was thinking of loading the metadata for the 1st track, then part of its audio, then metadata for all other tracks, then remaining audio |
| 00:13:50 | amiconn | preglow: Of course. The mentioned examples do far bigger ones (the biggest I am aware of is the old/new lcd decision on archos player (!)) |
| 00:14:11 | Nico_P | jhMikeS: well I don't fully understand those variations yet. when I say there's no constraint, it's theory. in practice we fill the audio spaces in sequential order |
| 00:14:28 | preglow | amiconn: i think isolated cases are completely ok, it doesn't add any real complexity, and having fewer builds makes up for it |
| 00:14:38 | * | gevaerts expects the runtime checks for the meizu to be much bigger |
| 00:14:44 | Nico_P | what I mean is that we could fill them in the order we want to |
| 00:14:56 | amiconn | The 2 LCDs have a completely different charset with a different number of user-definable characters, and completely different command sets too |
| 00:15:02 | jhMikeS | but a track won't start decoding until the metadata for it is ready so if that gets delayed...well, you get the idea |
| 00:15:38 | Nico_P | it shouldn't, but yeah I see what you mean |
| 00:15:51 | jhMikeS | the codecs wait for it internally |
| 00:15:58 | | Quit davina (Remote closed the connection) |
| 00:16:02 | amiconn | Well, the ipod color is a similar example (2 different LCDs). The ipod 1st/2nd Gen needs to decide on wheel enable, and adc read-out routine |
| 00:16:36 | jhMikeS | the current track should have buffering priority of course |
| 00:16:49 | amiconn | All bitmap archoses have several bits for selecting signal polarities. Oh, and the Ondio FM has 2 rather different tuner drivers... |
| 00:16:51 | markun | amiconn: the Meizu M3 needs to check for different LCD modules and different DACs. |
| 00:17:17 | Nico_P | jhMikeS: yes, but I think it's a good idea to only buffer part of its audio data and then move on to metadata for the following tracks |
| 00:17:26 | amiconn | So, such decisions are normal |
| 00:17:40 | Nico_P | and after that, fill all the remaining audio data |
| 00:17:41 | amiconn | I'm not sure about the 2 Mini builds though |
| 00:18:48 | | Quit [CBR]Unspoken|w (Connection timed out) |
| 00:18:53 | linuxstb | markun: All the different M3 versions look the same externally? |
| 00:19:05 | linuxstb | ^Meizu M3... |
| 00:19:19 | linuxstb | MM3? |
| 00:19:28 | markun | linuxstb: maybe the serial number starts differently |
| 00:20:05 | markun | the M6 models start with TP, SP, or SL |
| 00:20:09 | | Quit lee-qid (Read error: 110 (Connection timed out)) |
| 00:20:48 | Nico_P | jhMikeS: I could try to start implementing that maybe tomorrow, unless you want to do it |
| 00:21:44 | Nico_P | I also just started a reorganization of audio_check_new_track, but I think moving metadata loading to the buffering thread has more potential right now |
| 00:21:46 | jhMikeS | I'm working on Gigabeat S stuff atm |
| 00:21:52 | preglow | linuxstb: seems not all d2 units have dab :/ |
| 00:22:32 | Nico_P | jhMikeS: heh, then please don't change :) |
| 00:22:42 | linuxstb | preglow: Correct. |
| 00:22:48 | BigBambi | jhMikeS: \ô/ |
| 00:22:52 | linuxstb | I think Bagder has bought one without DAB. |
| 00:22:56 | preglow | damn, i'm itching for one of these buggers now |
| 00:23:02 | Nico_P | jhMikeS: did you see aliask's SPI patch btw? |
| 00:23:10 | Bagder | yes mine's without dab |
| 00:23:19 | | Quit XavierGr () |
| 00:23:19 | linuxstb | You _may_ need to buy it from the UK - I'm not sure where else they're sold with DAB. |
| 00:23:23 | markun | linuxstb: I talked to gevaerts about adding some runtime detection and optional macros to make an optimized build for a particular revision |
| 00:23:31 | preglow | linuxstb: i've found norwegian stores that claim to have ones with dab |
| 00:23:33 | * | amiconn would like a rockbox target with DAB support, but not touchy stuff like the D2 :\ |
| 00:23:39 | Bagder | I found it in Sweden with dab too |
| 00:23:46 | markun | Bagder: did you open it up yet? |
| 00:23:51 | Bagder | nope |
| 00:24:00 | linuxstb | OK - it was launched in the UK first, but obviously is now more widely available. |
| 00:24:20 | preglow | seems to cost around 2k nok for a dab one |
| 00:24:26 | Bagder | the D2 actually has screws visible |
| 00:24:41 | jhMikeS | BigBambi: :) BTW, what's \Ã'/ ?? (Visual IRC sucks with Unicode) |
| 00:24:41 | Bagder | the meizu seems harder to get into |
| 00:24:51 | markun | I didn't open mine |
| 00:25:02 | jhMikeS | Nico_P: no...someone should have said something :) |
| 00:25:03 | BigBambi | jhMikeS: It was an 'o' with a circumflex (a little hat) on it |
| 00:25:14 | preglow | don't think i'll end up justifying the cost when i've already got other mp3 players :/ |
| 00:25:19 | linuxstb | I would be curious to know if the DAB module is the same as the Logik DAX - I've documented the DAX on the wiki |
| 00:25:21 | BigBambi | in the middle of '\' and '/' |
| 00:25:23 | jhMikeS | \Õ/ |
| 00:25:24 | preglow | i need to get more advanced habits :P |
| 00:25:41 | BigBambi | jhMikeS: Nah, little hat not two dots |
| 00:25:57 | * | gevaerts prefers \☺/ |
| 00:26:03 | jhMikeS | that's an "O"+"~" here |
| 00:26:05 | * | Nico_P sees a flat hat in what jhMikeSsaid |
| 00:26:23 | BigBambi | Nico_P: what about ô vs ö |
| 00:26:30 | * | gevaerts sees a wavy hairstyle there |
| 00:26:40 | BigBambi | for me, first is little hat (not flat) second is two dots |
| 00:26:41 | Nico_P | BigBambi: there I see the difference |
| 00:27:16 | Nico_P | I guess my font is too small for jhMikeS' hair to be wavy |
| 00:27:20 | BigBambi | aha |
| 00:27:46 | BigBambi | jhMikeS: Anyway, originally it was an 'o' with a '^' on it :) |
| 00:28:05 | Nico_P | jhMikeS: it's FS #8792 in case you haven't seen yet |
| 00:28:42 | preglow | grah, the arm cores are quite nice too |
| 00:28:56 | jhMikeS | \Ø/ |
| 00:29:27 | * | jhMikeS wonders how he missed that FS |
| 00:29:45 | gevaerts | \☺/ \☻/ |
| 00:30:12 | markun | jhMikeS has a questionmark in his face for me... |
| 00:30:56 | | Quit ompaul (Client Quit) |
| 00:31:54 | | Quit toffe82 ("ChatZilla 0.9.81 [Firefox 2.0.0.13/2008031114]") |
| 00:32:50 | jhMikeS | Nico_P: It's stated it's not really an SVN suited patch. I was doing a interrupt-based one with nodes so it can handle all the SPI chips in the system (and read/write multiple values) |
| 00:33:26 | | Join midgey [0] (n=tjross@westquad-188-46.reshall.umich.edu) |
| 00:33:38 | Nico_P | jhMikeS: yes. I guess it might save you some time if it had stuff he found out |
| 00:33:55 | jhMikeS | we need read/write multiple to do backlight fading which is hardware controlled and needs two values sent withing 30uS. |
| 00:35:31 | preglow | Bagder: is the retailos usable? |
| 00:35:47 | Bagder | haven't tried it yet actually |
| 00:36:26 | Bagder | still doing the primary charging |
| 00:37:03 | Bagder | but it boasts flac and ogg playback etc |
| 00:38:08 | kugel | JdGordon: ping |
| 00:38:42 | jhMikeS | Nico_P: It'll probably be thread based (to allow sleeping) but actual handling of the PMU interrupts can be done on a worker thread. |
| 00:39:37 | shotofadds | preglow: assuming you're still taling D2, the retail firmware is actually usuable. |
| 00:39:42 | shotofadds | s/taling/talking |
| 00:39:55 | jhMikeS | btw, the processor is currently only running half speed after boot (the core clock divider is set to /2 by retailos so it's at 264 MHz). |
| 00:40:03 | preglow | shotofadds: cool, nice to be able to use it somewhat for videos and the like while porting |
| 00:40:24 | preglow | shotofadds: btw, do you know what clock the cores run at? i see from the wiki the second runs at 30 |
| 00:40:31 | preglow | 300 |
| 00:40:42 | shotofadds | the wiki is incorrect, in that case |
| 00:40:47 | preglow | really, now |
| 00:40:54 | Nico_P | jhMikeS: what about USB? |
| 00:41:00 | shotofadds | both cores run at up to 192Mhz |
| 00:41:12 | preglow | both seem to be pretty capable too |
| 00:41:14 | shotofadds | (although I have done no testing with COP whatsoever) |
| 00:41:47 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 00:42:22 | jhMikeS | Nico_P: I think the serial driver has to come first for detection. |
| 00:43:48 | linuxstb | preglow: According to the D2's manual, it can handle 320x240@30fps (MPEG4 or WMV) |
| 00:44:38 | preglow | linuxstb: which kind of sucks for tv out, but i guess it's far better than nothing |
| 00:44:49 | preglow | linuxstb: mpeg2 should decode more efficiently anyway |
| 00:44:50 | Nico_P | jhMikeS: do we know enough to be able to start implementing USB once the serial driver is ready, or is there more research needed? |
| 00:45:15 | amiconn | Does any of the new non-ipod colour targets actually have a reasonable LCD (i.e. not the pitch-black type)? |
| 00:45:55 | shotofadds | sadly the D2's is pitch-black |
| 00:46:05 | | Join wooster [0] (n=w@pool-70-107-93-184.ny325.east.verizon.net) |
| 00:46:10 | jhMikeS | Nico_P: I think there's not much more to know from the logic diagram. The tranceiver appears to be selected and controlled by OTG. |
| 00:46:11 | preglow | what is meant by pitch-black type? |
| 00:46:19 | shotofadds | not visible without backlight |
| 00:46:27 | preglow | :/ |
| 00:46:38 | Nico_P | jhMikeS: that means the imx31? |
| 00:46:47 | shotofadds | it's the same screen as the ZVM, actually. |
| 00:46:58 | linuxstb | shotofadds: Do you know if the D2 can do Band L DAB? |
| 00:47:14 | linuxstb | (Band 3 is used in the UK) |
| 00:47:14 | jhMikeS | Nico_P: yes. toffe82 said the CS pin is C10 which is USB_OC on the ball map |
| 00:48:19 | jhMikeS | Which seems to go against "CS(GPIO)". |
| 00:48:23 | shotofadds | linuxstb: I don't believe it can (though I can't recall where that answer came from) |
| 00:48:44 | linuxstb | shotofadds: I hope it can't (my Logik Dax can't either...) |
| 00:48:57 | shotofadds | linuxstb: I think it came from a Cowon Germany rep (re: ugrade to DAB+, etc) |
| 00:49:07 | | Quit herrwaldo ("Konversation terminated!") |
| 00:49:34 | linuxstb | What have they said about DAB+? |
| 00:49:38 | | Join CilliClone [0] (n=Cillian@client-86-31-46-131.leed.adsl.virgin.net) |
| 00:49:53 | kugel | JdGordon: In the hope you read the logs |
| 00:49:56 | CilliClone | Is it just me, or do rather a lot of jpegs not view correctly on rockbox? |
| 00:50:18 | linuxstb | CilliClone: Depends how many progressive jpegs you have - Rockbox can't view them. |
| 00:50:39 | linuxstb | Or what do you mean by "not view correctly" / |
| 00:50:56 | Bagder | http://daniel.haxx.se/docs/m6d2.html |
| 00:51:03 | shotofadds | well, since DAB is (apparently) being switched off in favour of DAB+ in Germany, users wanted to confirm the D2 is software-upgradeable. Apparently it is. |
| 00:51:06 | CilliClone | linuxstb: It gives an unsupported error |
| 00:51:08 | * | jhMikeS needs to see what "USB_OC" is anyway. |
| 00:51:10 | Bagder | shows the m6 next to d2 |
| 00:51:31 | CilliClone | I assume it's not reasonably simple for me to write a patch to fix that? |
| 00:52:00 | kugel | JdGordon: I'm refering to this i.e. function "void list_draw(struct screen *display, struct viewport *parent, struct gui_synclist *list)". It came with your list vp commit. I'm wondering what the "struct viewport *parent" is needed for, the gui_synclist struct has a parent vp within, this could be used, or am I missing something? |
| 00:52:01 | shotofadds | Bagder: the D2's a bit of a fatty compared to those two... |
| 00:52:16 | linuxstb | shotofadds: That's a good sign then - so we can implement it too... (the DAB+ specs are publically available for free) |
| 00:52:25 | | Quit dabujo (Read error: 104 (Connection reset by peer)) |
| 00:52:43 | preglow | linuxstb: that would seriously rock |
| 00:52:55 | * | kugel is jealous of all those d2 people :( |
| 00:53:07 | kugel | Good night |
| 00:53:10 | | Quit kugel ("ChatZilla 0.9.81 [Firefox 3.0b5/2008040514]") |
| 00:53:10 | wooster | This is going to be a bit orthagonal to the discussion, but I said I would report back, so pardon my pasting (I won't flood tho). |
| 00:53:18 | wooster | One week ago (Tue, Apr 1) I stopped in and asked about buying a refurb Sansa e260 from buy.com, wondering if it was version 1 and would therefore work with Rockbox. |
| 00:53:20 | * | shotofadds is jealous of all these targets with >1 developer :( |
| 00:53:28 | wooster | I got lots of help here, especially from BigBambi, pixelma and advcomp2019. I said I'd drop back by after it was delievered and so here I am to tell you that the buy.cm Sansa e260 that I got was indeed v.1 [FIRMWARE VERSION 01.02.18A ] and does work with Rockbox. |
| 00:53:49 | wooster | SO I'm happy. I presume this will always be a crapshoot but the 2 refurb Sansas I've gotten from Buy.com in the past month (this e260 and a recent c250) were both Rockbox-compatible. |
| 00:53:53 | BigBambi | wooster: Glad to hear it :) |
| 00:53:55 | shotofadds | linuxstb: DAB+ would rock, completely. How hard can it be.......? |
| 00:54:03 | wooster | ..end.. Sorry for the screen dump but I had it all typed out. |
| 00:54:15 | wooster | Thanks bigBambi, I appreciate your help! |
| 00:54:21 | wooster | it's great |
| 00:54:23 | BigBambi | no probs, anytime |
| 00:54:44 | preglow | shotofadds: he-aac isn't exactly a trivial decode, but it's completely doable on that core |
| 00:54:49 | wooster | ok, now I'll leave so you folks can continue making this great software. Bye! |
| 00:54:54 | linuxstb | shotofadds: Once DAB itself is working, supporting DAB+ should be trivial - we already have an aac+ decoder in Rockbox (I think...) |
| 00:54:56 | advcomp2019 | wooster, great to hear too and no problem |
| 00:54:59 | preglow | shotofadds: i'm seriously considering getting a d2 now |
| 00:55:06 | wooster | thanks adv2019 for your help... bye! |
| 00:55:12 | | Quit wooster () |
| 00:55:20 | linuxstb | shotofadds: The only issue will be optimising it - it may struggle... |
| 00:55:38 | | Quit jhulst_ (Remote closed the connection) |
| 00:55:39 | | Quit gevaerts ("Reconnecting") |
| 00:55:42 | | Join gevaerts [0] (n=fg@195-144-092-182.dyn.adsl.xs4all.be) |
| 00:55:46 | shotofadds | linuxstb: have you looked at DAB on the dax? |
| 00:55:51 | preglow | btw, what are the odds of bricking d2s? |
| 00:55:53 | linuxstb | Not at all. |
| 00:55:53 | | Join jhulst_ [0] (n=jhulst@unaffiliated/jhulst) |
| 00:56:02 | shotofadds | preglow: practically zero |
| 00:56:09 | shotofadds | I haven't managed it yet. |
| 00:56:13 | preglow | what i wanted to hear :) |
| 00:56:25 | linuxstb | preglow: There's a 4KB boot ROM in the SoC which gives a USB boot mode - that's what tcctool uses to transfer code to RAM |
| 00:56:30 | preglow | how far have you gone towards really trying to brick it, though? :P |
| 00:56:46 | shotofadds | linuxstb: did you look at any of the SDK links posted to the forum? there might be soemthing helpful in there, |
| 00:56:56 | shotofadds | linuxstb: it's 8kb btw |
| 00:57:04 | | Quit ender` (" Kids. You gotta love them. I adore children. A little salt, a squeeze of lemon--perfect. -- Harry Dresden") |
| 00:57:15 | * | jhMikeS wonders why one would want to "try" to brick a device |
| 00:57:18 | linuxstb | I thought it was 4KB... Or maybe that's the tcc77x |
| 00:57:44 | * | linuxstb needs to stop starting new things and go back to the logik dax |
| 00:57:45 | preglow | jhMikeS: well, not conciously try... |
| 00:57:45 | shotofadds | preglow: I don't think that's possible. If you even go as far as destroying the low-level format of the NAND it'll try to re-format it. |
| 00:58:05 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 00:58:05 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 00:58:45 | * | shotofadds is off to grab some much needed sleep. |
| 00:58:46 | jhMikeS | USB_OC = USB OUTPUT CONTROL (why doesn't the RM just say so) :p |
| 00:59:04 | linuxstb | shotofadds: Do you know if anyone has taken photos of the internals of a D2 DAB? |
| 00:59:12 | | Quit shotofadds (Read error: 104 (Connection reset by peer)) |
| 00:59:27 | saratoga2 | AAC+ decoding should be fine on an ARM9 core, even given our decoder |
| 01:00 |
| 01:00:06 | | Join Shaid [0] (n=adam@dsl-202-45-112-116-static.VIC.netspace.net.au) |
| 01:02:00 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
| 01:02:15 | preglow | saratoga2: sure, it should even be doable on an ipod core, given nicely optimized code |
| 01:02:25 | preglow | saratoga2: at least he-aac, parametric stereo might be asking for too much |
| 01:04:48 | | Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) |
| 01:05:37 | | Quit matsl (Remote closed the connection) |
| 01:07:58 | | Join perrikwp [0] (i=9821431b@gateway/web/ajax/mibbit.com/x-12d5a15d4c1eadaf) |
| 01:09:43 | jhMikeS | Nico_P: btw, on H10 I only see about 2s more buffering time over using the ata lock hack (and the disk is really slow on that). 22 vs 20 and I'm not sure it wasn't just some random variation. |
| 01:10:40 | Nico_P | I need to do some timing |
| 01:13:04 | | Quit spiorf (Remote closed the connection) |
| 01:15:22 | *** | Saving seen data "./dancer.seen" |
| 01:17:43 | | Join ol_schoola [0] (n=meatwad@c-67-167-20-91.hsd1.il.comcast.net) |
| 01:18:29 | jhMikeS | the only difference between 30gig and 60/80gig is the sector size? |
| 01:19:49 | gevaerts | jhMikeS: IIRC only the 80G has the 2k sectors (or maybe also the newer 30G) |
| 01:19:53 | pixelma | the main difference is RAM size (32 vs.64) and the 80GB disk has a different sector size (if I don't mix things up) |
| 01:20:16 | saratoga2 | preglow: I remember the Helix people claimed 80MHz or something equally ridiculous for ARM7 with 0 latency memory |
| 01:20:27 | saratoga2 | so i'm not too sure, at least not without dual core |
| 01:20:46 | pixelma | RAM size of 32 vs 64 _MB_ that is :) |
| 01:20:47 | DerPapst | 5.5G iPod have 2k sectors |
| 01:20:59 | | Quit jhulst_ (Remote closed the connection) |
| 01:21:14 | | Join jhulst_ [0] (n=jhulst@unaffiliated/jhulst) |
| 01:21:17 | * | jhMikeS sees MAX_PHYS_SECTOR_SIZE 1024 defined unconditionally in config-ipodvideo.h |
| 01:21:23 | DerPapst | so the 5.5G 30GB iPod has 2k sectors too |
| 01:22:04 | DerPapst | whereas the 5G 30GB one has 512byte sectors :-) |
| 01:22:20 | preglow | saratoga2: for aacplus version1 or 2? |
| 01:22:22 | * | gevaerts thinks the 5G is better : it has more sectors |
| 01:23:28 | saratoga2 | i think that was V1 only |
| 01:23:40 | amiconn | The 5.5G/80GB's *hard disk* has 1024-byte sectors |
| 01:23:54 | amiconn | All other ipod harddisks have standard 512-byte sectors |
| 01:23:58 | preglow | saratoga2: https://datatype.helixcommunity.org/2005/aacfixptdec.html |
| 01:24:13 | jhMikeS | 30g compiles with large sectors and an #error in the #define block confirms that |
| 01:24:22 | amiconn | However, the 5.5G 30GB *and* 80GB present their disk as having 2048-byte sectors *over USB* |
| 01:24:59 | amiconn | This means that the file system uses 2048-byte *logical* sectors |
| 01:25:30 | amiconn | jhMikeS: It's called MAX_PHSY_SECTOR_SIZE, not PHYS_SECTOR_SIZE |
| 01:25:48 | amiconn | The ata driver reads the actual physical sector size from the identify info |
| 01:26:05 | saratoga2 | ah so 60MHz ARM9TDMI, which is probably around 70MHz ARM7TDMI |
| 01:26:47 | preglow | deed |
| 01:26:56 | saratoga2 | doesn't fill me with hope |
| 01:26:59 | jhMikeS | amiconn: ok, but it's compiling with the lock hack too which means maybe I can actually test something |
| 01:27:10 | preglow | so we're go on d2, but not ipod |
| 01:27:21 | | Quit jhulst_ (Remote closed the connection) |
| 01:27:25 | saratoga2 | though maybe the SBR could be done on the COP |
| 01:27:34 | preglow | saratoga2: not impossible, no |
| 01:27:36 | amiconn | jhMikeS: Maybe, although the ata driver won't use the caching layer if the disk has 512-byte sectors |
| 01:27:40 | | Join jhulst_ [0] (n=jhulst@unaffiliated/jhulst) |
| 01:27:44 | amiconn | It could be forced to though |
| 01:27:58 | amiconn | ...on any disk-based rockbox target, btw |
| 01:28:52 | jhMikeS | I've forced the use of the caching layer on H10 with no trouble |
| 01:29:55 | amiconn | So maybe it's the filesystem and no the disk? |
| 01:30:36 | jhMikeS | not using the lock hack on 30gig is working fine too |
| 01:30:44 | jhMikeS | playing AAC and MP3 |
| 01:30:53 | amiconn | 5.5G? |
| 01:31:58 | jhMikeS | there's 5g and 5.5G 30gig? where do you find that out? there's nothing on the outside. |
| 01:32:33 | amiconn | Yes, both do exist |
| 01:32:57 | amiconn | The 5G has 512-byte logical sector in the filesystem, whereas the 5.5G has 2048-byte logical sectors |
| 01:34:15 | * | jhMikeS finds it odd that "View Disk Info" says nothing about this :) |
| 01:35:01 | critter- | which might be better in terms of long term replacement of batteries and hard drive the h320 or a ipod video 30gb ? |
| 01:35:49 | jhMikeS | amiconn: so phys_sector_mult would be 2? |
| 01:35:56 | amiconn | nope |
| 01:36:07 | amiconn | Don't confuse physical and logical sectors |
| 01:36:32 | jhMikeS | what here will tell me what I've got? |
| 01:36:34 | amiconn | The G5.5/30GB has ordinary 512-byte physical sectors, but 2048-byte logical sectors in the filesystem |
| 01:36:48 | jhMikeS | ok |
| 01:37:23 | linuxstb | Just running fdisk will tell you (or ipodpatcher) |
| 01:37:52 | amiconn | Meh, forgot ipodpatcher tells the sector size (was thinking about how to read that) |
| 01:38:05 | DerPapst | or the serial number ;-) |
| 01:38:28 | jhMikeS | ok, I didn't really pay too much attention |
| 01:38:44 | * | linuxstb wonders why he bothers making ipodpatcher show useful info ;) |
| 01:39:01 | Cannoli | quick question, what is the name of the file that needs to be put into a folder if u dont want to add it to the database? |
| 01:39:18 | DerPapst | database.ignore iirv |
| 01:39:21 | DerPapst | *iirc |
| 01:39:41 | | Quit Chronon_ ("User pushed the X - because it's Xtra, baby") |
| 01:39:58 | Cannoli | kk and if i put that in root it should ignore everything right? |
| 01:40:09 | DerPapst | yes |
| 01:40:38 | jhMikeS | [INFO] Ipod found - Video (aka 5th Generation) ("winpod") - disk device 2 |
| 01:40:38 | jhMikeS | [INFO] Reading partition table from \\.\PhysicalDrive2 |
| 01:40:38 | jhMikeS | [INFO] Sector size is 2048 bytes |
| 01:40:50 | Cannoli | alright and iirc database.unignore should add the mp3 files in the database where the unignore file is? |
| 01:41:00 | DerPapst | yes |
| 01:41:03 | Cannoli | kk ty |
| 01:41:39 | | Join Chronon [0] (i=vircuser@d23-104.uoregon.edu) |
| 01:42:30 | amiconn | jhMikeS: Ah, so it's a G5.5 |
| 01:42:36 | * | DerPapst thinks he should get some sleep... |
| 01:43:07 | jhMikeS | so here, no hack = just great :) |
| 01:43:25 | amiconn | But why does the 80GB need the hack, then? |
| 01:43:56 | amiconn | Because of the 1024-byte physical sectors? Unlikely, because you tested with the caching layer. |
| 01:44:10 | amiconn | Because of the RAM size? No idea how likely that would be |
| 01:44:19 | jhMikeS | I have no idea unless something unrelated is wrong there |
| 01:44:31 | DerPapst | But then the 60GB 5G would suffer from that too. |
| 01:44:53 | amiconn | Hmm, but you could try forcing the caching layer on the G5.5/30GB, as that gives a combination you didn't test yet, but the G5.5/80GB represents |
| 01:45:12 | amiconn | 1024-byte physical sectors *and* 2048-byte logical sectors |
| 01:45:26 | jhMikeS | will do. what should be changed to force that? |
| 01:45:41 | DerPapst | Good night everyone :-) |
| 01:45:47 | jhMikeS | nighty |
| 01:46:15 | amiconn | Just replace the detection (lines 1262..1266) in the ata driver with an assignment: phys_sector_mult = 2; |
| 01:46:23 | | Quit gevaerts ("good night") |
| 01:46:23 | | Part DerPapst |
| 01:48:03 | | Quit moos (Read error: 110 (Connection timed out)) |
| 01:48:13 | amiconn | It's not actually a multiplier, it just limits the ata driver to read/write sectors in multiples of that number, and also aligned according to it |
| 01:48:57 | | Quit Mathiasdm ("Yuuw!") |
| 01:49:01 | | Part CilliClone |
| 01:49:42 | | Join corevette [0] (n=corevett@adsl-75-18-212-2.dsl.pltn13.sbcglobal.net) |
| 01:49:54 | jhMikeS | still seems ok |
| 01:51:09 | | Join simonrvn [0] (i=simon@unaffiliated/simonrvn) |
| 01:51:58 | jhMikeS | all the combos of locking / size are pretty indistiguishable in behavior |
| 01:57:11 | jhMikeS | I compiled this for 32MB ram, it should be 64MB? |
| 01:57:35 | amiconn | No, unless you want to see rockbox crash ;) |
| 01:58:07 | amiconn | Only the 60GB (G5) and 80GB (G5.5) models have 64MB ram |
| 01:58:23 | jhMikeS | ok but that pretty much leaves that as the only variable here |
| 01:58:56 | amiconn | Could also be rockbox settings differences |
| 02:00 |
| 02:00:02 | amiconn | Iirc I did some quick checks on other targets when this bug was reported, and couldn't reproduce the problem.... until a couple of days later I loaded cabbiev2. |
| 02:00:30 | stripwax | is the bug being discussed the skipping/gapping/buffering behaviour on startup? |
| 02:00:30 | jhMikeS | I do have cabbiev2 loaded. Perhaps resume to playback will do something. |
| 02:00:31 | amiconn | Changed back to a sane wps, and the problem went away... might be solved meanwhile thanks to bmp strips |
| 02:00:40 | jhMikeS | *restart |
| 02:03:17 | amiconn | Maybe that too. I don't normally use that (always start in file broswer for me) |
| 02:03:17 | Nico_P | stripwax: hi! did you see that sliding puzzle is now using the smooth bitmap resize? |
| 02:03:21 | | Quit hd (Client Quit) |
| 02:03:38 | stripwax | Nico_P - I did! :) haven't tried it out yet though |
| 02:04:28 | stripwax | amiconn/jhMikeS - fwiw (if you're talking about what I think you're talking about), I get that from time to time, with 5g 60 GB, using cabbiev2 |
| 02:04:57 | stripwax | if that doesn't add any new datapoints please ignore me :) |
| 02:05:12 | * | jhMikeS has cabbiev2, database update, dircache scan and resume at startup without any unresponsiveness or dropouts |
| 02:05:42 | Nico_P | jhMikeS: the dircache scan doesn't seem to change anything for me |
| 02:05:55 | stripwax | I do have albumart |
| 02:06:08 | stripwax | (but I don't have database enabled) |
| 02:06:10 | * | jhMikeS has that too |
| 02:07:22 | stripwax | my resume on startup resumes into the middle of quite a long playlist also |
| 02:07:34 | | Join toffe82 [0] (n=chatzill@adsl-75-23-148-240.dsl.frs2ca.sbcglobal.net) |
| 02:08:02 | jhMikeS | all the disk bound threads are clawing away for it and it responds to input like nothing is running |
| 02:08:21 | stripwax | and my albumart is all called "cover.bmp" in the same folder as the corresponding audio file. trying to think whatever other differences there might be |
| 02:09:48 | stripwax | when I get a chance I'll put on the latest build and see if anything got better. I'm running one from a few days ago |
| 02:09:58 | | Quit stripwax ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 02:11:18 | * | Nico_P goes to bed |
| 02:11:42 | | Join hd [0] (i=jd@unaffiliated/helldragon) |
| 02:11:45 | | Quit Nico_P (Remote closed the connection) |
| 02:13:29 | jhMikeS | the database thread is occasionally being bumped from 20 to 15 (buffering priority) so I know that's working properly and there's contention |
| 02:20:27 | | Quit miepchen^schlaf () |
| 02:20:44 | | Join miepchen^schlaf [0] (n=miepchen@p54BF76F4.dip.t-dialin.net) |
| 02:24:10 | | Join Mario_372 [0] (n=Mario_37@71.31.237.36) |
| 02:24:40 | | Part pixelma |
| 02:24:54 | | Join junzi [0] (n=tharg@pool-71-247-61-117.nycmny.east.verizon.net) |
| 02:28:23 | Mario_372 | can someone help me fix a sansa? |
| 02:30:09 | |
icon identifies that the person is a core developer (has commit access).