--- Log for 22.10.120  Server: wilhelm.freenode.net  Channel: #rockbox
--- Nick: logbot_  Version: Dancer V4.16  Started: 24 days and 20 hours ago

00.41.52 ***     Saving seen data "./dancer.seen"
01.59.26 #       <efqw> update regarding battery bench:
02.00.09 #       <efqw> if I shut down rb and actually put the microsd into my computer, I do get the logs
02.00.24 #       <efqw> but I don't see anything if I `cat` the file in the console
02.00.39 #       <efqw> so I assume everything was written when rb quits?
02.00.44 #       <efqw> this is odd
02.04.53 Join    Stanley00 [0] (~stanley00@unaffiliated/stanley00)
02.06.07 #       <Stanley00> I also tried battery_bench on my M5, with in-ear phone, it reported about 9h playing to go from 100% to 5%
02.06.21 #       <Stanley00> *in-ear headphone
02.07.20 #       <efqw> yeah, I have some low-impedance stuff plugged in as well to simulate regular usage
02.29.28 #       <_bilgus__> are you guys using the test audio files for this?
02.30.59 Quit    _3dsv (Ping timeout: 240 seconds)
02.32.44 #       <efqw> I was not aware of the existence of a test audio file.
02.33.05 #       <efqw> I just picked a random flac album I had
02.33.22 #       <_bilgus__> https://www.rockbox.org/wiki/CodecPerformanceComparison#Requirements
02.34.31 #       <Stanley00> I also used my own flac album
02.34.36 #       <_bilgus__> they are under codec tests but it gives a good base line for testing BB and doing codec bench too
02.35.00 #       <_bilgus__> assuming your player handles them all without crashing
02.35.40 #       <efqw> I'll do the codec bench after the bettery bench is done.
02.36.15 #       <_bilgus__> its probably jaw dropping fast on that processor
02.36.52 #       <efqw> yeah, that's what I'd expect tbh :P
02.38.35 #       <efqw> something like 5000%+ perhaps
02.41.56 ***     Saving seen data "./dancer.seen"
02.42.05 Join    _3dsv [0] (~3dsv@068-184-255-059.res.spectrum.com)
03.18.03 Join    petur [0] (~petur@77.77.179.66)
03.18.03 Quit    petur (Changing host)
03.18.03 Join    petur [0] (~petur@rockbox/developer/petur)
03.48.37 Quit    Rower (Read error: Connection reset by peer)
03.49.01 Join    Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
04.41.59 ***     Saving seen data "./dancer.seen"
04.57.40 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
05.19.01 #       <Stanley00> I'm working on the poweroff issue on m5
05.19.28 #       <Stanley00> https://github.com/jerome-pouiller/ioctl <= not sure if we can use this and call to it to shutdown axp after issue the poweroff command
05.24.54 Join    prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net)
05.28.58 #       <Stanley00> yup, it works on m5... if you all agree on this, we can just have something like `system("poweroff; sleep 10; ioctl /dev/axp173 magic_number");`
05.52.50 Quit    prof_wolfff (Ping timeout: 256 seconds)
06.25.37 Join    Rower- [0] (~Rower@185.246.208.202)
06.27.58 Quit    Rower (Ping timeout: 256 seconds)
06.31.15 #       <wodz> speachy: do you by any chance know how asound.conf values corelate with alsa device string? I mean I am looking way to avoid dynamicaly crafting entry in asound.conf file for bt devices
06.42.00 ***     Saving seen data "./dancer.seen"
07.01.25 Join    Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
07.05.08 Quit    Rower- (Ping timeout: 272 seconds)
07.09.09 #       <speachy> wodz: type:deviceid[,subdevice]
07.09.41 #       <Stanley00> efqw: https://pastebin.com/raw/0WN8HyUV <= my current work-around for poweroff issue
07.10.22 #       <wodz> speachy: how to pass device specific params?
07.11.10 #       <speachy> 'hw:0' is usually all that's needed for native hw but you're locked into hw capabilities only, 'plughw:0' is the wrapper that will do conversions/etc for you if the hw doesn't do what you want
07.12.09 #       <speachy> what sort of params?  (I don't think you specify that in the devicestring, that's either in asound.conf or you specify the options when doing your hw/swparams setup api calls...)
07.12.26 #       <Stanley00> speachy: I'm having weird issue with M5 volume button. it won't take effect until I press pause and the play the current song. Do you have any idea what may causing this?
07.12.52 #       <speachy> (it's been well over a decade since I've done anything substantial with alsa..)
07.13.20 #       <wodz> speachy: For each bt device hiby creates entry in asound.conf like this pcm.80_C7_55_63_59_D6{
07.13.20 #       <wodz>     type bluetooth
07.13.20 #       <wodz>     bdaddr 80:C7:55:63:59:D6
07.13.20 DBUG    Enqueued KICK wodz
07.13.20 #       <wodz>     profile a2dp
07.13.20 #       <wodz> }
07.13.52 #       <wodz> then you can reference this as alsa device '80_C7_55_63_59_D6'
07.14.15 #       <speachy> if you do 'aplay -l' it will show you the perspective from alsa's api
07.14.22 #       <wodz> I would prefer to avoid writing entries in aplay.conf
07.14.47 #       <wodz> **** List of PLAYBACK Hardware Devices ****
07.14.47 #       <wodz> card 0: k1 [k1], device 0: k1-cs42l51 cs42l51-hifi-0 []
07.14.48 #       <wodz>   Subdevices: 1/1
07.14.48 ***     Alert Mode level 1
07.14.48 #       <wodz>   Subdevice #0: subdevice #0
07.14.53 #       <wodz> not really helpful
07.14.53 #       <speachy> I don't know if that's possiblem.  :/
07.17.56 #       <wodz> bluealsa can do that
07.18.08 #       <wodz> the string is like this bluealsa:DEV=00:0B:D5:F5:F8:B9,PROFILE=a2dp
07.18.50 #       <speachy> you beat me to it.  :)
07.18.52 #       <wodz> since bluealsa is based on pcm plugin from bluez4 I thought it would be possible here as well
07.19.59 #       <speachy> I'd bet bluealsa's using a /etc/asound.conf that's been parameterized.
07.20.07 #       <speachy> see https://volkerschatz.com/noise/alsa.html
07.20.41 #       <speachy> search for '@args'
07.23.43 #       <wodz> ok, now that starts to make sense
07.24.03 Join    cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
07.24.20 #       <wodz> when parametrization was introduced? Maybe we can do the same
07.24.49 ***     Alert Mode OFF
07.24.56 #       <speachy> I'd be shocked if it wasn't supported on those hiby targets.
07.25.15 #       <speachy> I _think_ they have alsa 1.0.26?  circa 2013-ish.
07.25.27 #       <speachy> parameters are probably at least a decade older
07.26.45 #       <wodz> good so it is a matter of crafting parametrized config
07.26.46 #       <speachy> so we can add a generic parameerized bluetooth entry at the end of /etc/asound.conf when we patch in the bootloadr, or of hiby_player mucks with it (ie strips it out) we can do it the startup script that launches the loader
07.27.03 #       <wodz> exactly
07.27.43 Quit    Stanley00 ()
07.27.44 #       <speachy> btw, tools/hiby_patcher.pl is what's used to mangle the update.upt images these days.
07.28.26 #       <wodz> https://github.com/Arkq/bluez-alsa/blob/master/src/asound/20-bluealsa.conf
07.29.45 #       <wodz> looks like changing type from bluealsa to bluetooth should do the trick
07.30.42 #       <wodz> I mean pcm part
07.30.51 #       <speachy> yepper
07.33.16 Join    MrZeus_ [0] (~MrZeus@185.195.232.139)
07.34.18 #       <speachy> Stanley00, does the volume display change when you hit the buttons?
07.35.40 #       <speachy> Also, you need to run battery_bench until the device shuts down.  the last time I did a bench run on an uncalibrated device, it was under 10% for over five hours.
07.49.28 #       <wodz> speachy: Sometimes I can get aplay to work with bt, but mostly I get this
07.49.30 #       <wodz> Playing WAVE 'test_file.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
07.49.30 #       <wodz> ALSA lib audio/pcm_bluetooth.c:2056:(audioservice_recv) Too short (0 bytes) IPC packet from bluetoothd
07.49.30 #       <wodz> aplay: set_params:1166: Unable to install hw params:
07.49.30 #       <wodz> ACCESS:  RW_INTERLEAVED
07.49.30 #       <wodz> FORMAT:  S16_LE
07.49.33 #       <wodz> SUBFORMAT:  STD
07.49.35 #       <wodz> SAMPLE_BITS: 16
07.49.37 #       <wodz> FRAME_BITS: 32
07.49.39 #       <wodz> CHANNELS: 2
07.49.41 #       <wodz> RATE: 44100
07.49.43 #       <wodz> PERIOD_TIME: (46439 46440)
07.49.45 #       <wodz> PERIOD_SIZE: 2048
07.49.47 #       <wodz> PERIOD_BYTES: 8192
07.49.49 #       <wodz> PERIODS: 3
07.49.51 #       <wodz> BUFFER_TIME: (139319 139320)
07.49.53 #       <wodz> BUFFER_SIZE: 6144
07.49.55 #       <wodz> BUFFER_BYTES: 24576
07.49.57 #       <wodz> TICK_TIME: [0 0]
07.49.59 #       <wodz> and bluetoothd dies
07.50.03 #       <wodz> any idea?
08.36.29 #       <speachy> not particularly. nothing of use in the bluetoothd logs?
08.42.04 ***     Saving seen data "./dancer.seen"
08.43.21 #       <speachy> maybe it wasn't actively paired at the itme?
08.44.10 #       <wodz> bt-device -i reported paired and connected
08.46.22 #       <wodz> Battery is dying in my device. This complicates everything further
08.47.45 Join    prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net)
09.10.18 Join    t0mato2 [0] (~t0mato@193.32.127.162)
09.10.50 Quit    t0mato (Ping timeout: 256 seconds)
09.10.50 Nick    t0mato2 is now known as t0mato (~t0mato@193.32.127.162)
09.19.51 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09.30.16 Join    Stanley00 [0] (~stanley00@unaffiliated/stanley00)
09.30.41 #       <Stanley00> speachy: yes, the volume icon changed as I pressed the volume buttons
09.31.10 #       <Stanley00> I also tried change volume from sound setting but it's still won't effect until I paused the current playing
09.34.56 Quit    Stanley00 (Read error: Connection reset by peer)
09.36.34 #       <efqw> it's been more than 7 hours and the m3k's battery is still at 3.863v
09.36.59 #       <efqw> I think it's pretty safe to assume this thing can do more than 14hrs
09.39.41 Join    Stanley00 [0] (0135c695@unaffiliated/stanley00)
09.41.55 #       <Stanley00> since the poweroff is working on my m5 now, I guess I can do the battery_benchmark this weekend
09.42.49 #       <Stanley00> also, where can I find the bluetooth code for hosted targets? I grep through the rockbox master but I can't find any
09.43.18 #       <Stanley00> and what can I expected from current bluetooth support for hosted targets?
09.46.02 Quit    Stanley00 (Remote host closed the connection)
09.48.22 Join    Stanley00 [0] (0135c695@unaffiliated/stanley00)
09.55.30 Quit    pamaury (Ping timeout: 272 seconds)
09.57.35 Quit    Stanley00 (Remote host closed the connection)
09.59.58 #       <efqw> there is no BT code *at all* yet
10.07.22 Join    Stanley00 [0] (0135c695@unaffiliated/stanley00)
10.08.05 #       <Stanley00> efqw: oops, I thought I heard we have somewhat bluetooth for hosted here :(
10.08.25 #       <Stanley00> anyway, did you check my work-around for m3k poweroff issue?
10.08.41 #       <efqw> it's still doing the battery bench :P
10.09.35 #       <Stanley00> I see
10.10.08 #       <Stanley00> FiiO stated that m5 can last for 10 hours, so I could be happy with around 9 hours for rockbox
10.10.40 #       <Stanley00> consider I didn't tune and turn off unneeded chipset/peripherals yet
10.11.29 #       <Stanley00> funny thing is my laptop sometimes can see my M5 via bluetooth while I boot rockbox
10.24.39 #       <efqw> for me a dedicated DAP needs a fairly good battery life that lasts through multiple listening sessions without needing to recharge
10.28.53 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
10.29.12 Quit    massiveH (Quit: Leaving)
10.30.54 Quit    Stanley00 (Ping timeout: 245 seconds)
10.42.07 ***     Saving seen data "./dancer.seen"
10.57.48 Quit    Oksana (Ping timeout: 260 seconds)
11.07.20 Join    Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide)
11.16.20 #       <speachy> Stanley00:  the m5 is a modification of the existing m3k/fiio drivers, correct?
11.24.24 Quit    petur (Quit: Connection reset by beer)
11.25.05 Join    Stanley00 [0] (0135c695@unaffiliated/stanley00)
11.25.25 #       <Stanley00> sorry, I got very unstable network here
11.27.56 Quit    Stanley00 (Remote host closed the connection)
11.29.08 Join    Stanley00 [0] (0135c695@unaffiliated/stanley00)
11.29.47 #       <Stanley00> if you're asking about the volume buttons issue. All I changed that can related to sound is replace '/dev/ak4376' to /dev/ak4377 on m5
11.30.53 #       <Stanley00> one side note is it used to worked before when I edit m3k code directly, but then I pull the master branch, and create separated files for m5, the issue appears
11.47.09 Quit    Stanley00 (Ping timeout: 245 seconds)
11.49.37 Join    Stanley00 [0] (0135c695@unaffiliated/stanley00)
11.50.05 #       <Stanley00> speachy: I think I found it, https://github.com/Rockbox/rockbox/blame/master/firmware/drivers/audio/fiiolinux_codec.c#L94 <= this muted supposed to be initialized by 0 instead?
11.50.52 #       <speachy> mute state wouldn't affect the inability to adjust the volume when playing (assuming you could hear anything to start with)
11.52.04 #       <Stanley00> but later, at line 129, it won't enter the code to apply volume,
11.54.01 #       <speachy> add  audiohw_mute(false); to the end of audiohw_preinit()
11.54.50 #       <Stanley00> it make sense. So, we use value of -1 for another special meaning of muted state then?
11.55.21 #       <speachy> thats to make sure we explicitly call audiohw_mute()
11.55.35 #       <speachy> instead of relying on something happening implicitly.
11.56.20 #       <speachy> not entirely clear it'll do any good on this platform
11.56.42 #       <speachy> since there's no dedicated mute control on the audio path
11.57.09 #       <speachy> oh!  everyone, gerrit's going offline in a few minutes.
11.57.21 #       <speachy> anongit and gitweb will continue fine
11.59.14 Quit    Stanley00 (Ping timeout: 245 seconds)
12.01.23 #       <speachy> and it's now offline.
12.02.45 Quit    MrZeus_ (Ping timeout: 240 seconds)
12.03.31 Join    Stanley00 [0] (0135c695@unaffiliated/stanley00)
12.09.17 #       <efqw> `up 10:07,  0 users,  load average: 2.08, 2.04, 2.05`
12.09.34 #       <efqw> battery still at 3.825v
12.09.48 #       <efqw> don't tell me this is gonna last 20h, lol
12.14.24 #       <fs-bluebot_> Build Server message: New build round started. Revision 97b8692, 293 builds, 9 clients.
12.15.25 #       <speachy> ok, gerrit is back up.
12.16.19 Join    MrZeus_ [0] (~MrZeus@185.195.232.139)
12.18.24 Quit    Stanley00 (Ping timeout: 245 seconds)
12.24.35 #       <speachy> Stanley00:  I committed that change I suggested.  tbh I'm not sure how you got _any_ sound out at all without it.
12.26.13 #       <speachy> never say never!  :D
12.26.26 #       <speachy> aro you playing that flac file, or something else?
12.29.40 #       <fs-bluebot_> Build Server message: Build round completed after 915 seconds.
12.29.49 #       <fs-bluebot_> Build Server message: Revision 97b8692 result: All green
12.30.31 Join    Stanley00 [0] (0135c695@unaffiliated/stanley00)
12.32.33 #       <Stanley00> my collections is mostly flac, with a few mp3 and ogg
12.32.58 #       <Stanley00> there's maybe some code path relate to play/pause logic that effect the volume, I guess
12.36.42 Quit    Stanley00 (Quit: Ping timeout (120 seconds))
12.42.08 ***     Saving seen data "./dancer.seen"
12.43.18 #       <speachy> do you have current code otherwise?
13.13.47 Join    Stanley00 [0] (0135c695@unaffiliated/stanley00)
13.14.39 #       <Stanley00> I was trying latest code from master before bed, but it looks like you forgot to update muted variable in audiohw_mute =]]
13.15.45 #       <speachy> ...oh, lovely.
13.16.11 #       <speachy> that's what happens when I can't test the code I'm changing
13.16.43 #       <fs-bluebot_> Build Server message: New build round started. Revision 02c5dd3, 293 builds, 9 clients.
13.20.07 #       <_bilgus__> and what happens when I _CAN_ test the code I'm changing :p
13.20.31 #       <Stanley00> it's time for bed, good night everyone
13.26.47 #       <_bilgus__> night
13.27.35 #       <Stanley00> okay, now's bed time storry: I'm testing the test_files earlier, and it seems that ape_c5000 is killing my m5... cpu top at 97% and the sound is lagging... =]]
13.28.07 #       <_bilgus__> __builtin you mentioned xworld does it use xlcd or are the unrelated?
13.28.20 Part    Stanley00
13.30.55 #       <speachy> Stanley000, APE @c5K is ... quite intensive.
13.30.59 #       <fs-bluebot_> Build Server message: Build round completed after 856 seconds.
13.31.01 #       <fs-bluebot_> Build Server message: Revision 02c5dd3 result: All green
13.31.02 #       <fs-bluebot_> Build Server message: New build round started. Revision 1e12990, 293 builds, 9 clients.
13.32.34 #       <_bilgus__> thats why I mentioned 'if the player can play them'
13.33.28 #       <_bilgus__> I tell you what though I'm still tired of that song that most of the test files use
13.35.59 #       <speachy> most (all?) of our targets can't handle ape @c4K either.
13.44.18 #       <fs-bluebot_> Build Server message: Build round completed after 798 seconds.
13.44.20 #       <fs-bluebot_> Build Server message: Revision 1e12990 result: All green
14.02.25 Join    lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
14.21.09 Quit    pamaury (Ping timeout: 265 seconds)
14.41.42 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
14.42.12 ***     Saving seen data "./dancer.seen"
15.00.46 #       <_bilgus__> well I tried and failed to make xlcd stride agnostic, oh well I left the pieces in there for anyone who wants to expand it
15.01.22 #       <_bilgus__> getting tired of this patch, get it working then expand from there
15.06.22 #       <_bilgus__> OK g#2811 SHOULD be ready!
15.06.24 #       <fs-bluebot_> Gerrit review #2811 at http://gerrit.rockbox.org/r/2811 : LCD core move buf ptr and address look up function viewport struct by William Wilgus
15.06.38 #       <speachy> 25th time's the charm, eh?
15.06.55 #       <_bilgus__> look at the advanced keylock patch I think I had 50
15.07.55 #       <_bilgus__> I do try to tend to push my days work up there so I can read through it on breaks
15.09.18 #       <_bilgus__> there is still 2bit corruption on non-native strides but I want to get all these other targets right that can be a different patch since nothings using it ATM
15.10.41 #       <speachy> it works!
15.10.51 #       <speachy> okay, this is... funny
15.11.07 #       <speachy> I hit play on the UIsim on my workstation, and music started playing out of my laptop.
15.11.46 #       <_bilgus__> I didn't do that!
15.12.21 #       <_bilgus__> g#1417 I guess it was only 40 patch sets
15.12.23 #       <fs-bluebot_> Gerrit review #1417 at http://gerrit.rockbox.org/r/1417 : Selective Backlight/Advanced Softlock - Selective actions based on context by William Wilgus
15.12.36 #       <speachy> I must have paired them via bluetooth at some point because nothing else makes any sense
15.13.18 #       <_bilgus__> adv keylock was actually much more difficult but this one is far more annoying and sprawled out
15.14.45 #       <_bilgus__> I'll commit this by the weekend assuming no more flaws pop up
15.15.51 #       <speachy> can't say I've run into anything new, but it does fix two bugs I've personally tripped over.
15.16.17 #       <_bilgus__> I think the other thing I want to do is to wire the dirty vp stuff a little deeper in the core to the point that it will not refresh a vieport that is already clean
15.16.59 #       <_bilgus__> bugs you found prior to this rewrite? NO way :p
15.17.55 #       <speachy> of course not, rockbox's code is pristine and perfect, as was handed down by the Swedish Demigods
15.18.27 #       <_bilgus__> If I had to guess one of the bugs was the wps thing and a stride issue in plugins?
15.19.03 #       <speachy> display&|viewport corruption in multiple plugins and that wps thing.
15.19.27 #       <speachy> possible this likely fixes some of the crash-on-exit plugin issues seen on the hosted targets
15.20.22 #       <_bilgus__> well it does force vp init now on plugin start and cleans it up on exit
15.21.03 #       <_bilgus__> before it was just kinda luck of the draw
15.21.19 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
15.21.19 #       * speachy nods.
15.51.27 Quit    MrZeus_ (Ping timeout: 260 seconds)
15.58.47 #       <speachy> grr, gitlab oauth integration into our gerrit instance is still shot
16.04.42 Join    MrZeus_ [0] (~MrZeus@185.195.232.139)
16.06.27 #       <_bilgus__> reviewing the framebuffer patch I see a lot of code for clipping that could probably be moved to a clip func ptr within the viewport
16.07.47 Quit    fs-bluebot_ (Ping timeout: 260 seconds)
16.07.48 #       <_bilgus__> same ida as the fb address function pointer, I mean it could be moved there as well but I wouldn't want the overhead on every pixel
16.07.54 Join    fs-bluebot [0] (~fs-bluebo@55d45674.access.ecotel.net)
16.10.28 #       <speachy> I like the sound of that.
16.10.56 #       <_bilgus__> hmm I really didn't consider the implications on the bootloaders I wonder how much of this code they pull in
16.12.23 #       <speachy> most of 'em don't display anything at all.
16.13.17 #       <speachy> so I expect minimal effect on bl code size.
16.14.11 #       <_bilgus__> heeh I already got a error :p
16.14.42 #       <_bilgus__> time to upgrade my toolchain
16.14.43 #       <speachy> might have IRAM size problems.
16.14.49 #       <_bilgus__> lol
16.15.09 #       <_bilgus__> do I just rebuild off the new rbdev.sh?
16.16.30 Quit    pamaury (Ping timeout: 258 seconds)
16.16.43 #       <speachy> I'd recommend moving the old ones out of the way rather than installing over them, but otherwise it's just run and wait a while.
16.20.45 Quit    Rower (Ping timeout: 240 seconds)
16.21.22 #       <_bilgus__> ok when I get back I shall continue this adventure
16.21.42 #       <speachy> only (native) arm and m68k changed
16.28.30 #       <_bilgus__> was about to ask
16.38.20 #       <braewoods> _bilgus__: well i know the h120 bootloader does display stuff to remote LCD
16.38.24 #       <braewoods> and the native one
16.38.53 #       <braewoods> but just text
16.40.24 #       <_bilgus__> as longas it doesn't do scrolling should be ok and I believe I pulled scrolling from all bootloaders at some point
16.42.14 Quit    Oksana (Ping timeout: 256 seconds)
16.42.16 ***     Saving seen data "./dancer.seen"
16.55.15 Join    Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide)
17.28.32 Quit    lebellium (Quit: Leaving)
18.42.18 ***     Saving seen data "./dancer.seen"
19.19.57 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
19.19.57 Join    fs-bluebot_ [0] (~fs-bluebo@55d44bc9.access.ecotel.net)
19.22.23 Quit    fs-bluebot (Ping timeout: 260 seconds)
19.23.14 Quit    bluebrother^ (Ping timeout: 265 seconds)
19.35.07 Join    Alexander [0] (53d58627@39.83-213-134.dynamic.clientes.euskaltel.es)
19.35.32 Nick    Alexander is now known as Guest40192 (53d58627@39.83-213-134.dynamic.clientes.euskaltel.es)
19.36.13 #       <Guest40192> Hey there! So i encountered an "error/bug" of some sort. Should i expose it here, or where should i head to?
19.36.59 Nick    Guest40192 is now known as zazuradia (53d58627@39.83-213-134.dynamic.clientes.euskaltel.es)
19.38.26 #       <zazuradia> I mean, my player model is iPod 6G 160GB and i installed Rockbox less than a month ago.
19.43.04 Quit    MrZeus_ (Ping timeout: 256 seconds)
19.51.00 #       <speachy> first, are you using the 3.15 release or a dev/nightly build?
19.52.41 #       <zazuradia> it says 3.15 in the Info section. and i don't use to install nightly nor dev builds.
19.55.01 #       <speachy> please see if the issue is stull present in a recent nightly or dev build, and if it still is, then it's worth talking about
19.55.58 #       <speachy> FWIW I'm not aware of any reason to not be using a dev/nightly build
19.57.05 #       <zazuradia> i avoid them in general because of potential stability problems.
19.57.57 #       <braewoods> i think that's more true for recent ports
19.57.58 #       <zazuradia> the "bug" is just that the player refuses to play any file beyond 14 hours. (ie: audiobooks, which is the main reason i use this ipod)
19.59.12 #       <speachy> yeah, please make sure it's still present first
19.59.23 #       <speachy> I cant' say I've personally tried anything over about 9h.
19.59.26 #       <zazuradia> i just say it plain and simple because it may have to do with some kind of filesystem or hardware limitation already known. i've googled like an hour and didn't find anything related to rockbox that could be of use.
20.00.33 #       <braewoods> zazuradia: is this a single file that's 14 hours+ or a bunch of files adding up to 14 hours+?
20.01.58 #       <zazuradia> single files only. i've aded many days worth of music to the database and it plays as expected. but when it comes to a file longer than 14h it just skips it and starts playing the next one.
20.03.41 #       <braewoods> encoded as mp3?
20.04.16 #       <braewoods> this may be an area that isn't well tested since i can't say i know many people that encode single files that long
20.04.57 #       <zazuradia> mpeg-4, 134kbps vbr,
20.05.03 #       <braewoods> so AAC?
20.05.58 #       <braewoods> either way first thing to try is a development build
20.05.59 #       <zazuradia> the file properties say mpeg-4, but i encoded them with the "send itunes as audio track" tool on mac.
20.06.13 #       <braewoods> i see.
20.07.27 #       <zazuradia> i just installed the lates dev build i found, rebooted, tried to play and it skips every track over 14h
20.07.48 #       <braewoods> i wonder if it's something to do with RAM or so...
20.07.55 #       <braewoods> hm
20.08.16 #       <braewoods> zazuradia: one idea, see if encoding one of those files temporarily as something else like Opus would change anything
20.08.57 #       <braewoods> it may help narrow it down to codec specific issue vs general decoding issue
20.09.15 #       <braewoods> though it may simply be running into some kind of limiter on length
20.12.22 Join    Stanley00 [0] (~Stanley00@unaffiliated/stanley00)
20.12.54 #       <braewoods> zazuradia: i assume you haven't modified yours with a higher capacity drive or so?
20.13.06 #       <braewoods> RB has known issues if used with iflash
20.13.46 #       <zazuradia> nope. only a sticker for the screen. everything else is out of the box. not even the hard drive or the battery
20.14.34 #       <Stanley00> FYI: bbout ape file last night, m5 can handle c4000 with 60% cpu usage
20.14.45 #       <Stanley00> about*
20.16.02 #       <zazuradia> braewoods: i could try to reencode the file i have, but i can't output any other format in the mac's built-in tool
20.16.29 #       <braewoods> wasn't saying you should... i've never used ipods myself.
20.16.35 #       <braewoods> i mean
20.16.38 #       <braewoods> with their tool
20.16.55 #       <braewoods> you'd probably have to install third party tools to do it
20.18.07 #       <zazuradia> also worth noting, i started using rockbox on this "newer" ipod because the (stock firm) 5G gave me problems keeping track on files over 14h too.
20.19.22 #       <zazuradia> i mean, the files played well, but when i tried to ff or rw when reached that limit, if i tried to do it it would freeze, start over or skip the track.
20.19.39 #       <braewoods> just how long are your audio books?
20.19.51 #       <braewoods> most things i know of would split them across multiple files
20.21.40 #       <zazuradia> for example, the longest one is IT (S. King) with almost 23 hours.
20.22.29 #       <zazuradia> i "make" them myself and leave them single filed for as long as they would go. i have no way of knowing how long will it end up being.
20.23.22 #       <braewoods> well, transcoding them as a more compact format like Opus may help narrow it down
20.23.24 #       <Stanley00> Hmm... 14h is like 50.000 seconds. Maybe there's limit at 65536 or something like that?
20.24.10 #       <braewoods> it would be closer to 18h if that was the case
20.25.20 #       <Stanley00> zazuradia: how did you come up with 14h limit, do you have other file that last around 10h?
20.25.51 #       <Stanley00> May be it's 32768 limit for signed type
20.27.51 #       <braewoods> 32767 actually
20.27.57 #       <braewoods> :)
20.28.27 #       <zazuradia> well, not seconds, but since this is a device intended to play music, maybe it calculates the time in minutes, and it doesn't have the capacity to track minute quantities over 4 digits, but 999 minutes is like 16h, and that doesn't match either.
20.31.16 #       <zazuradia> (i'm trying to reencode the file to ogg, btw. but it's a huge file and it's taking some time)
20.31.48 Quit    Acou_Bass (Ping timeout: 256 seconds)
20.42.20 ***     Saving seen data "./dancer.seen"
20.44.55 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
20.48.32 Quit    Stanley00 ()
20.52.41 #       <speachy> zazuradia: oh, it's mp4?  yeah, that's definitely a problem for larger files.
20.53.38 #       <braewoods> speachy: why?
20.53.44 #       <braewoods> ram requirements?
20.54.05 #       <zazuradia> i have a file that is 14h exactly and another one 13 and a half or so. one of them doesn't play and the other does perfectly
20.54.19 #       <speachy> the container is more oriented towards streaming.
20.54.54 #       <braewoods> is the same true for opus then? it was originally conceived for realtime audio streams
20.55.14 #       <speachy> fs#13159
20.55.17 #       <fs-bluebot_> http://www.rockbox.org/tracker/task/13159 rockbox hangs on certain m4a files (bugs, unconfirmed)
20.55.25 #       <speachy> I reported this bug over two years ago.  :D
20.56.44 #       <speachy> basically parsing the stream is memory intensive.
20.57.04 #       <braewoods> my first hunch was some kind of RAM limiter
20.57.19 #       <speachy> IIRC on less-ram-blessed targets the failure point happens a lot earlier (~6-7h, I think)
20.59.31 #       <zazuradia> i could give you the gdrive link for the 14h file, if you want to try anything.
20.59.52 #       <braewoods> i'll give it a try
21.00.01 #       <zazuradia> https://drive.google.com/file/d/1s1mtKRdYavGnE-5CUrfNylWynZustNDn/view?usp=sharing
21.00.17 #       <zazuradia> (it's in spanish, and pretty fast, btw)
21.01.26 #       <braewoods> most of my rockboxs have 32MB
21.03.04 #       <braewoods> zazuradia: for reference the upper limit is 2TB for storage media for RB, if that's even possible to achieve
21.03.12 #       <braewoods> depends on the port as well
21.03.34 #       <braewoods> but 2TB is the limiter inherited from the disk label most use
21.03.53 #       <braewoods> though i have seen a few targets that use no partition table
21.05.08 #       <zazuradia> my ipod are windows formated. do you think this would change if i mac partitioned them?
21.05.29 #       <braewoods> yes
21.05.35 #       <braewoods> and RB would no longer work
21.05.46 #       <zazuradia> oops. XDD
21.06.23 #       <_bilgus__> braewoods has it try opus or flac
21.06.31 #       <speachy> (or even mp3)
21.06.57 #       <_bilgus__> 14 hours is excessive
21.06.59 #       <braewoods> not yet. i'm about to myself but it takes time
21.07.25 #       <speachy> It's not clear yet if SDUC (ie >2TB cards) required changes to the SD command protocol.
21.08.45 #       <braewoods> i'll see what happens once this is done
21.10.53 #       <zazuradia> omg. i changed the format (from whatever itunes uses, mp4, aac...) to ogg and it seems to work. :)
21.11.15 #       <_bilgus__> :((( [ERR]  Packed data (135305 bytes) doesn't fit in the firmware (134008 bytes)
21.11.20 #       <zazuradia> i mean, i recoded the complete file. it took a little while. ^_^U
21.11.24 #       <_bilgus__> I KNEW IT!
21.11.44 #       <_bilgus__> !k is a lot of code
21.11.53 #       <_bilgus__> 1k*
21.11.55 #       <speachy> _bilgus__: what target?
21.12.10 #       <_bilgus__> clip+ its the one thast closest to the line
21.12.21 #       <_bilgus__> multiboot was within 30 bytes
21.12.36 #       <_bilgus__> 30 BYTES! lol
21.15.04 #       <braewoods> opus is encoding at 48x
21.15.06 #       <braewoods> raltime
21.15.08 #       <braewoods> lol
21.15.21 #       <braewoods> first hour is nearly done
21.15.47 #       <zazuradia> do you know of any offline converter?
21.15.51 #       <braewoods> zazuradia: realistically your best option is opus. it's fairly CPU friendly and is very compact in terms of audio.
21.16.03 #       <braewoods> zazuradia: uh...
21.16.12 #       <braewoods> zazuradia: i'm just using a command line approach
21.16.26 #       <braewoods> faad Memorias\ de\ idhun\ 2\ Triada.m4a -o /dev/stdout | opusenc - Memorias\ de\ idhun\ 2\ Triada.opus
21.16.29 #       <braewoods> for my test
21.16.51 #       <braewoods> it will probably lose metadata
21.16.53 #       <braewoods> but
21.17.01 #       <braewoods> a more professional tool can probably help there
21.17.21 #       <braewoods> i'll see if this works
21.17.24 #       <braewoods> let me finish encoding first
21.17.31 #       <braewoods> at 3 hour mark
21.17.53 #       <braewoods> this is with my quad core ivy bridge laptop
21.18.10 #       <braewoods> 49.6x
21.18.56 #       <braewoods> 17% faad, 100% opusenc lol
21.19.09 #       <_bilgus__> personally flac is better optimized and faster encoding too
21.19.26 #       <speachy> but a real waste of disk space for a 14h audio book.
21.19.27 #       <braewoods> but it's lossless so more space consumption
21.19.31 #       <zazuradia> hmm. command line isn't friendly enough. i would need some kind of front-end so i could batch reencode files.
21.19.41 #       <braewoods> indeed.
21.19.51 #       <_bilgus__> zazuradia, linux?
21.19.52 #       <braewoods> right now i'm just trying to re-encode this one file to see how it compares.
21.19.56 #       <zazuradia> win10
21.19.57 #       <braewoods> he's using Mac
21.19.59 #       <braewoods> or
21.20.00 #       <braewoods> that
21.20.06 #       <braewoods> i just assumed lol
21.20.20 #       <braewoods> at 5 hour mark
21.20.51 #       <braewoods> this'll take around 20 minutes
21.20.55 #       <braewoods> at 48x
21.21.01 #       <zazuradia> nah, i use mac only for that tool, but i bootcamped my laptop quite long ago. i don't like mac, but it's the only thing i know of that has this handy tool.
21.21.17 #       <_bilgus__> windows how about audacity it has a batch convert mode
21.21.29 #       <braewoods> does that include metadata translation?
21.21.43 #       <braewoods> to the extent that is possible
21.21.45 #       <braewoods> anyway
21.21.52 #       <_bilgus__> doubtful if you want that the music brainz might help after the fact
21.22.27 #       <braewoods> hm AAC is fairing better than I expected
21.22.39 #       <braewoods> i guess opus isn't able to dip the bitrate as much
21.22.49 #       <_bilgus__> pretty sure it includes scripting support so not too hard to get a transfer method going
21.23.28 #       <braewoods> interestingly i think opus will end up around 20% smaller
21.23.39 #       <braewoods> 8 hour mark
21.24.22 #       <zazuradia> 50% smaller in my case
21.24.31 #       <braewoods> for ogg?
21.24.36 #       <braewoods> it probably dropped the bitrate
21.24.40 #       <braewoods> heavily
21.24.45 #       <zazuradia> around 800mb to around 400
21.24.48 #       <braewoods> opus is around the same bitrate
21.25.01 #       <zazuradia> nah, from 134 vbr to 128. i don't need more than that.
21.25.06 #       <braewoods> i see.
21.25.12 #       <braewoods> maybe ogg is better sometimes.
21.25.22 #       <braewoods> i thought opus was always the king lol
21.25.51 #       <zazuradia> well, since it's not music i'm working with, i'm okay with pretty low quality, if this means i'm gonna save on disk space.
21.26.27 #       <braewoods> i've mainly used opus to avoid having tradeoffs in ripped CD tracks
21.26.32 #       <braewoods> they're much smaller than mp3s
21.26.58 #       <braewoods> 3.3 hours to go :x
21.27.45 #       <zazuradia> many years ago i would care about codec compatibility, but it's nothing to worry about today. rockbox and vlc got me covered.
21.29.29 #       <speachy> ok...32-bit to 38-bit addressing.   But the old address field was only 32-bit.
21.31.47 #       <speachy> which implies new CMDs were defined.
21.32.34 #       <__builtin> _bilgus__: xworld and xlcd are unrelated
21.32.53 #       <braewoods> zazuradia: 13% smaller
21.33.02 #       <__builtin> xworld's name was inspired by xrick, which was sitting in gerrit around the same time
21.33.10 #       <zazuradia> same settings, i guess?
21.33.24 #       <_bilgus__> ok I was just making sure, I had started converting xlcd to arbitrary strides but it kept causing issues
21.33.41 #       <speachy> unless someone happens to have a copy of the SD 7.0/7.1 specs lying around....
21.33.55 #       <braewoods> zazuradia: -shrug- But it works.
21.34.02 #       <braewoods> so whatever works i guess lol
21.34.05 #       <braewoods> anything but AAC
21.34.07 #       <_bilgus__> also the patch is up on gerrit if you want to check out the changes that apply to your babies I'd highly appreciate it
21.34.14 #       <_bilgus__> @__builtin
21.34.21 #       <_bilgus__> 2811
21.34.33 #       <__builtin> alright, I'll take a look
21.34.42 #       <__builtin> "my babies" :)
21.35.52 #       <_bilgus__> for the most part I only gave them their own FB I didn't do anything to optimize beyond using rb->screens[MS].currentvp for stuff that needs performance it a lot
21.36.06 #       <zazuradia> oh yeah. when i started using this tool i used to end up with files above 9GB, for some reason. the tool saves a huge file to the desktop, THEN it recodes it through itunes and saves it in it's directory system. i learned this second file sounds about the same and it's like 1/10 the size.
21.36.48 #       <_bilgus__> 'it a lot' yeah no clue either..
21.37.22 #       <__builtin> doesn't look like a huge change to my plugins at least
21.37.33 #       <__builtin> if it compiles I've got no issue with it
21.40.31 #       <speachy> So the question is.. did they bump up the block size from 512B to 32K, or did they define a new cmd to allow specifying the extra 6 bits?
21.47.26 Quit    cockroach (Quit: leaving)
21.51.44 #       <zazuradia> okay guys, it's pretty late here and i kind of need a little bit of sleep.
21.52.16 #       <zazuradia> THANKS A LOT for the help solving my problem. i can't thank you enough.
21.52.19 #       <zazuradia> see ya!
21.53.27 #       <zazuradia> oh btw, i started a thread on the forums before anyone here responded, so i marked it as [SOLVED] and replied with the answer and the steps for the workaround. :)
21.54.14 #       <_bilgus__> __builtin, thanks
22.05.23 Quit    zazuradia (Remote host closed the connection)
22.16.38 Quit    prof_wolfff (Ping timeout: 256 seconds)
22.42.21 ***     Saving seen data "./dancer.seen"
22.53.19 #       <_bilgus__> speachy WELL it turns out that the bootloader doesn't fit @ head either [ERR]  Packed data (135305 bytes) doesn't fit in the firmware (134008 bytes)
22.53.45 #       <_bilgus__> let me double check that I'm not doing something stupid
22.57.05 #       <_bilgus__> so yeah my patch doesn't increase the size at all but now gonna have to find 1K somewhere
22.57.59 #       <_bilgus__> speachy does the buildfarm create bootloader builds anymore?
22.59.03 #       <_bilgus__> AHH I bet the build but don't go through the mkamsboot stuff
22.59.09 #       <_bilgus__> they*
23.20.04 #       <speachy> yeah, they just genetate the binaries.
23.20.14 #       <speachy> as in whatever 'make' generates
23.21.46 #       <speachy> wonder where teh size bump came from.    (git-bisect?)
23.21.54 #       <speachy> (new toolchain?)
23.23.03 #       <_bilgus__> maybe and that might be why I was sticking to the old one originally but can't say for sure
23.24.13 #       <_bilgus__> I do know buffers in bss are inconsequential (~20 bytes each) because of the compression
23.24.55 #       <_bilgus__> so this is going to be a stictly code game I already did this once to get MB inthere so the easy stuff is gone
23.25.19 #       <_bilgus__> rtl language support can probably go
23.25.54 #       <_bilgus__> diacritics can probably get condensed to a single codepage or so
23.27.32 #       <_bilgus__> if we make the boot logo the size of the screen (if its not already) we can get rid of the lcd buffer probably not too much there on the clip+ though
23.28.24 #       <_bilgus__> oh yeah 20 bytes!
23.35.32 #       <_bilgus__> wonder what buflib is used for in the bootloader
23.44.52 Quit    [7] (Disconnected by services)
23.44.58 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)
23.45.31 #       <_bilgus__> well printf is using 2k wonder if unneeded things are being exposed again
23.48.59 #       <_bilgus__> maybe it is time to put in a tiny limited printf with the bootloaders
23.56.41 #       <_bilgus__> looks pretty standard bootloaders use printf snprintf springt {vsnprintf}
23.56.59 #       <_bilgus__> and I see %x %d %ld %s %02d 0x%02x %.4s
23.57.26 #       <_bilgus__> so standard types and still need precision and padding
23.58.20 #       <_bilgus__> wonder what our old printf looks like from before this expansion by JhMikes