| 00:04:20 | | Quit zem (Ping timeout: 252 seconds) |
| 00:06:18 | | Join zem [0] (~zem@97-115-91-140.ptld.qwest.net) |
| 00:14:38 | | Quit dconrad (Remote host closed the connection) |
| 00:19:39 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 00:22:51 | | Quit advcomp2019 (Quit: Leaving) |
| 00:23:05 | | Join advcomp2019 [0] (~advcomp20@user/advcomp2019) |
| 00:24:06 | | Quit dconrad (Ping timeout: 246 seconds) |
| 01:00 |
| 01:26:34 | *** | Saving seen data "./dancer.seen" |
| 01:55:12 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 01:59:46 | | Quit dconrad (Ping timeout: 248 seconds) |
| 02:00 |
| 02:35:03 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 02:38:09 | | Quit advcomp2019 (Ping timeout: 246 seconds) |
| 03:00 |
| 03:26:38 | *** | Saving seen data "./dancer.seen" |
| 03:33:45 | | Join lebellium [0] (~lebellium@2a01cb0405d07f0081f11f53f0942b2b.ipv6.abo.wanadoo.fr) |
| 04:00 |
| 04:04:29 | | Join _bilgus_ [0] (~bilgus@syn-162-154-213-134.res.spectrum.com) |
| 04:06:14 | | Quit _bilgus (Ping timeout: 245 seconds) |
| 04:23:31 | | Join advcomp2019__ [0] (~advcomp20@user/advcomp2019) |
| 04:26:39 | | Quit advcomp2019_ (Ping timeout: 246 seconds) |
| 04:57:21 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 05:00 |
| 05:01:49 | | Quit dconrad (Ping timeout: 252 seconds) |
| 05:26:42 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:54:49 | | Join Jinx [0] (~Jinx@user/jinx) |
| 07:00 |
| 07:26:46 | *** | No seen item changed, no save performed. |
| 08:00 |
| 08:08:29 | speachy | ugh, utf8proc compiles so a 350K binary on x86_64, nearly all of which is its data tables. |
| 09:00 |
| 09:26:47 | *** | No seen item changed, no save performed. |
| 09:40:49 | | Quit speachy (Quit: WeeChat 4.3.5) |
| 09:55:51 | | Join speachy [0] (~speachy@hurricane.shaftnet.org) |
| 09:55:51 | | Quit speachy (Changing host) |
| 09:55:51 | | Join speachy [0] (~speachy@rockbox/developer/speachy) |
| 09:55:51 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 10:00 |
| 10:35:13 | | Join npmania_ [0] (~npmania@210.123.73.190) |
| 10:38:17 | | Quit npmania (Ping timeout: 252 seconds) |
| 10:38:18 | | Nick npmania_ is now known as npmania (~npmania@210.123.73.190) |
| 11:00 |
| 11:02:52 | _bilgus_ | thats around half of our firmware size |
| 11:03:26 | speachy | that will get us full case folding, normalization and de-normalization. |
| 11:18:05 | speachy | And that still won't solve whatever issue OlsroFR ran into. :D |
| 11:19:39 | speachy | (and heh it's Ols*r*oFR) |
| 11:21:50 | rb-bluebot | Build Server message: New build round started. Revision 142003328d, 337 builds, 10 clients. |
| 11:21:50 | rb-bluebot | Translation updates: by Solomon Peachy |
| 11:23:45 | speachy | there's a big RU update too, but I'm still waiting on the FullName of the submitter |
| 11:26:51 | *** | Saving seen data "./dancer.seen" |
| 11:32:46 | rb-bluebot | Build Server message: Build round completed after 656 seconds. |
| 11:32:47 | rb-bluebot | Build Server message: Revision 142003328d result: All green |
| 11:36:06 | _bilgus_ | speachy is dconrads 5914 sufficient or do we need to do something with target as well? |
| 11:36:57 | speachy | it needs some changes, but in principle it's sufficient. |
| 11:52:07 | _bilgus_ | target or model? or leave it be for later changes? |
| 12:00 |
| 12:02:48 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 12:40:17 | speachy | they don't need a unique model_id in C-land, we can roll the EROSQK_VER define into the header file... |
| 12:40:43 | speachy | might as well get it right now. :D |
| 12:40:56 | speachy | (my comments are on the changeset) |
| 13:00 |
| 13:10:48 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 13:15:29 | | Quit dconrad (Ping timeout: 260 seconds) |
| 13:26:53 | *** | Saving seen data "./dancer.seen" |
| 13:42:42 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 13:49:04 | | Join TheEaterOfSouls [0] (~souls@user/TheEaterOfSouls) |
| 13:49:20 | | Quit dconrad (Ping timeout: 255 seconds) |
| 15:00 |
| 15:03:34 | | Join OlsroFR [0] (~OlsroFR@user/OlsroFR) |
| 15:04:13 | OlsroFR | speachy Wow even full normalization does not fix it. I know that it's coming from that because I could notice it by saving the playlist |
| 15:04:51 | OlsroFR | I did 2 tests. First test with a database on device by playing the same album and everything worked. Then I export a playlist from that dynamic playlist. I can play just find the saved playlist and everything works |
| 15:05:33 | OlsroFR | But I then did the same with the database created by the linux Docker image and then I compared the 2 text files and I noticed that accented characters were encoded using a different utf normalization |
| 15:06:09 | speachy | so, which one is "correct"? |
| 15:06:27 | speachy | as in, what does the actual on-disk filename consist of? |
| 15:07:21 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 15:08:08 | speachy | and was the linux docker stuff directly accessing the player's filesystem? |
| 15:09:24 | OlsroFR | Yeah the Docker stuff was accessing the device using a docker volume. No choice to do that. I am on a Mac arm64 so I cannot execute linux arm64 binaries stuff directly (and was not motivated to boot a virtual machine just for that, I thought it logical to do all the work directly from Docker so I could build a multi-platform script that could be |
| 15:09:24 | OlsroFR | enjoyed by Windows and Linux users of Rockbox) |
| 15:09:46 | speachy | oh, so you're using this via MacOS. |
| 15:10:18 | speachy | that might "helpfully" be doing normalization behind the scenes. nothing we can do about the OS lying to us about filenames. |
| 15:10:23 | OlsroFR | Docker Desktop on MacOS Sonoma, all updated |
| 15:11:07 | OlsroFR | https://workupload.com/archive/8tzjSAeTNF here is a link to my 2 playlists |
| 15:11:42 | | Quit dconrad (Ping timeout: 246 seconds) |
| 15:11:52 | OlsroFR | The 2 playlist files seems to be both exactly identical excepted the "é" accent |
| 15:13:44 | OlsroFR | the "é" accent that is working is character code "233". The one that does not work is 2 code points : "101,769" |
| 15:14:15 | OlsroFR | https://www.mauvecloud.net/charsets/CharCodeFinder.html you can copy paste characters here to get their real code |
| 15:14:20 | speachy | this is firmly in CantFix territory. |
| 15:14:29 | speachy | nothing we can do if the OS lies about the filenames. |
| 15:15:07 | OlsroFR | What I can do is probably 2 things : build it for Linux then use a linux virtual machine and pray that it will work |
| 15:15:23 | OlsroFR | the other one would be to build it for Windows then run it on a virtual machine or in wine |
| 15:15:41 | OlsroFR | but I can't manage to build it for Windows, I get many build errors |
| 15:16:58 | OlsroFR | _bilgus_ I will do tests tomorrow, thanks. Seems interesting. I decided to not really fill all the available space because it was enough for me to get perfectly balanced segments. But well you did it, so I will test your code and review it |
| 15:18:33 | OlsroFR | speachy https://www.rockbox.org/wiki/Windows10CrossCompiler#Build_Simulator This doc seems to be updated, as installing just as descripted the things in my Docker container still throw errors like an SDL error+speachy |
| 15:20:42 | speachy | I don't personally care at all about issues pertaining to MacOS or Windows. |
| 15:21:09 | speachy | patches and/or documentation welcome, but they are very much SomeoneElse'sProblem(tm) |
| 15:21:48 | OlsroFR | Have you tried the dbtool on a real linux machine just for curiosity ? Could you reproduce the issue with accents ? |
| 15:22:58 | OlsroFR | I will try to do something like a virtual machine. I am motivated to get it working, since it is building the whole db in only a few minutes compared to one hour on device... I hope I will find a workaround that works for me |
| 15:23:18 | speachy | I fixed issues with the dbtool a few months or so ago, but I didn't specifically validate utf-8 encoded stuff was handled properly. |
| 15:24:20 | OlsroFR | Normalizing utf should (in theory) improved the reliability of the code. But it's not a good idea to do it on device because it will add a lot of overhead |
| 15:25:08 | speachy | where overhead == ~50% jump in code size. |
| 15:25:08 | OlsroFR | Can you send me your prototype if you've already integrated the lib ? So I can do tests and I will tell you if it can fix the issue |
| 15:26:42 | OlsroFR | the overhead seems to be no big deal for me as long as it's not compiled on devices but only for the PC tool so everything will work right in this context. Getting special characters in file names happens all the time and using a tool like "detox" is stripping way too much like all japanese characters which does not work because it create on my |
| 15:26:42 | OlsroFR | device several empty folders |
| 15:26:55 | speachy | it's not a simple thing to integrate. again, filenames are opaque byte sequences. if we normalize things we also have to be able to map them back to the on-disk representation, so in effect that means doubling the space used when referenceing files. |
| 15:26:57 | *** | Saving seen data "./dancer.seen" |
| 15:27:58 | OlsroFR | Yes that's why I tried to normalize myself my filesystem using commands to do utf normalization but it didn't work, it's annoying. It's like the fs commands can lie compared to the real byte sequence |
| 15:28:06 | speachy | because we have to store both the raw form and the normalized form that is displayed. |
| 15:28:53 | speachy | so it actually is a "big deal" :D |
| 15:29:34 | OlsroFR | Can be an issue from Docker also. I tried to change the implementation about storage, there's 3 virtual implementations for this. But it didn't work with any of them |
| 15:30:18 | speachy | I know MacOS normalizes filenames on HFS+ (and presumably APFS). It's not much of a stretch to assume it does it for everything else too. |
| 15:31:06 | OlsroFR | A virtual machine can in theory bypass completely how the host is handling file systems if I connect the device directly to it and let the virtual OS mount it |
| 15:31:18 | OlsroFR | I am going to try this |
| 15:31:41 | speachy | Docker is still relying on the host platform and is affected by its semantics. |
| 15:32:04 | OlsroFR | I will use Docker now just to produce the binary |
| 15:50:22 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 15:50:22 | | Quit othello7 (Read error: Connection reset by peer) |
| 15:53:03 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 15:57:05 | | Quit othello7 (Read error: Connection reset by peer) |
| 16:00 |
| 16:03:42 | | Quit Tonux (Quit: Bye) |
| 16:04:26 | | Join Tonux [0] (~Tonux@193.32.127.216) |
| 16:08:59 | | Join Tonux_ [0] (~Tonux@193.32.127.216) |
| 16:10:38 | | Quit Tonux (Ping timeout: 255 seconds) |
| 16:10:40 | | Nick Tonux_ is now known as Tonux (~Tonux@193.32.127.216) |
| 16:11:46 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 16:20:02 | OlsroFR | I did 2 things |
| 16:20:02 | OlsroFR | - Changed my Docker image to compile on Ubuntu 22.04 rather than Ubuntu 24.04 (because it's difficult/annoying to install directly Ubuntu 24.04 also on my virtual machine and I noticed that a program compiled on ubuntu 24.04 can't run on Ubuntu 22.02) |
| 16:20:03 | OlsroFR | - I ran the databasetool on my Ubuntu 22.04 virtualmachine. I forced the ipod to connect as a real device on the VM. |
| 16:20:10 | OlsroFR | With this configuration, it worked ! |
| 16:23:01 | OlsroFR | OK. Now I tried to compile & run again with Docker. It failed again, in Ubuntu 22.04. So it means that the issue is not related to the Ubuntu version by itself. |
| 16:23:28 | OlsroFR | Now I am going a last thing, I am going to try on my machine virtual again but by using a virtual folder for the device rather than USB passthrough |
| 16:25:38 | OlsroFR | building the database from a virtual folder seems so much slower compared to USB passthrough |
| 16:26:31 | OlsroFR | OK it failed. Same issue. |
| 16:26:49 | speachy | ....because MacOS is normalizing filenames returned through readdir(). |
| 16:26:51 | OlsroFR | +speachy I think you are right, MacOS is the problem |
| 16:27:30 | OlsroFR | Anything that goes through MacOS is normalized. What a stupid thing to do lol. I thought that they stopped doing this with APFS |
| 16:27:47 | OlsroFR | I could not find many recent info about this, most people talking about this were talking about this from HFS+ era |
| 16:32:04 | | Quit jacobk (Ping timeout: 260 seconds) |
| 16:33:53 | OlsroFR | Anyway, I am happy to have a solution that is really working. It's a bit overkill to boot up a whole vm each time I want to build the database, but well, it's working perfectly. I am not going to try to build a Windows version of this, it will be probably time waste since Wine will still rely from the host implementation of low level fs calls |
| 16:39:53 | OlsroFR | The database builder is so fast, it's so exciting to bypass the 1 hour creation on device. Booting a VM for this totally worth it. I would not be surprise that it could work all from Docker on a Windows host because it does not mess with unicode normalization |
| 16:40:34 | OlsroFR | Linux hosts will probably also do the job all from Docker. Only MacOS seems affected by this lol |
| 16:41:07 | OlsroFR | I feel so wrong on MacOS right now, but well, this will be good to provide accurate documentation. I plan to write a tutorial for all of this on Reddit and to share my Docker scripts :) |
| 16:44:59 | | Quit OlsroFR (Quit: Client closed) |
| 17:00 |
| 17:26:59 | *** | Saving seen data "./dancer.seen" |
| 17:43:31 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 18:00 |
| 18:15:25 | munkis | What is the current state of bluetooth on the Eros Q? |
| 18:16:23 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 18:19:22 | speachy | "Boot into the manufacturer firmware if you want to use it." |
| 18:20:01 | munkis | ah so the WIPs are still pre alpha. Thanks |
| 18:20:36 | speachy | I wouldn't even go that far. |
| 18:20:40 | | Quit dconrad (Ping timeout: 252 seconds) |
| 18:22:29 | speachy | the base (hosted) platform uses an ancient bluetooth userspace and the audio interface doesn't work with the async ALSA APIs that we use. |
| 18:23:16 | speachy | to fix the latter we'd have to rework how we do our threading so we can create a dedicated audio output thread that uses synchronous (or polling) API calls. |
| 18:24:43 | speachy | on native platforms, there is precisely one BT stack that is technically suitable, but it has incompatible licensing terms. |
| 18:25:10 | | Quit lebellium (Quit: Leaving) |
| 18:25:12 | speachy | (effectively "BSD, but noncommerical only" |
| 18:34:37 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 18:35:15 | | Quit othello7 (Quit: othello7) |
| 19:00 |
| 19:19:07 | dconrad | speachy now that I look at it, I don't think I can remove the extra gcc option - there doesn't seem to be any other defines we can determine the version from in the makefile |
| 19:20:41 | dconrad | we need to do decisionmaking in firmware/export/config.h on what export/config header file to import |
| 19:24:13 | dconrad | I think perhaps we could use an option in the configure script like debug or logf...? |
| 19:25:06 | | Quit GeekShadow (Ping timeout: 246 seconds) |
| 19:25:48 | dconrad | well, really more like have_fmradio_in |
| 19:27:00 | *** | Saving seen data "./dancer.seen" |
| 19:27:28 | dconrad | like usual, it's more complicated than I wish it was haha |
| 19:45:45 | munkis | Maybe I should see if I can stuff an off-the-shelf bluetooth adapter into my fuze+ case. (or perhaps 3d print a slightly larger one) |
| 19:53:04 | dconrad | Well, unfortunately I can't get rid of all the weirdness, but I think I can make it a little more sane in tools/configure |
| 20:00 |
| 20:05:39 | | Join massiveH [0] (~massiveH@2600:4040:a982:dc00:5031:f049:1a3a:8e15) |
| 20:28:37 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 20:34:30 | dconrad | speachy: if you want to take another look at g#5914, I think it's a little cleaner now - I still need an extra option added in tools/configure to denote hw version, but hopefully this is ok |
| 20:34:33 | rb-bluebot | Gerrit review #5914 at https://gerrit.rockbox.org/r/c/rockbox/+/5914 : erosqnative: Give erosqnative_v3 its own target ID and modelname by Dana Conrad |
| 21:00 |
| 21:02:37 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 21:12:13 | | Join GeekShadow [0] (~antoine@lbf.turmel.info) |
| 21:27:04 | *** | No seen item changed, no save performed. |
| 21:48:08 | | Quit Moriar (Quit: Leaving.) |
| 22:00 |
| 22:09:15 | | Quit jackie (Ping timeout: 265 seconds) |
| 22:09:28 | | Quit dconrad (Remote host closed the connection) |
| 22:09:48 | | Join jackie [0] (~jackie@banana-new.kilobyte22.de) |
| 22:19:09 | | Quit jacobk (Ping timeout: 260 seconds) |
| 22:54:54 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 22:55:36 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 23:00 |
| 23:15:08 | | Quit massiveH (Quit: Leaving) |
| 23:27:08 | *** | Saving seen data "./dancer.seen" |
| 23:42:16 | | Quit dconrad (Remote host closed the connection) |
| 23:43:10 | | Join dconrad [0] (~dconrad@152.117.104.217) |
| 23:47:43 | | Quit dconrad (Ping timeout: 252 seconds) |
icon identifies that the person is a core developer (has commit access).