| 00:03:07 | | Join jacobk [0] (~quassel@2600:1700:5410:dae0:e18d:d5ee:bc4:7950) |
| 00:31:14 | | Quit othello7 (Ping timeout: 248 seconds) |
| 00:43:19 | | Quit jacobk (Ping timeout: 260 seconds) |
| 01:00 |
| 01:36:44 | *** | Saving seen data "./dancer.seen" |
| 01:37:04 | | Join advcomp2019__ [0] (~advcomp20@user/advcomp2019) |
| 01:40:29 | | Quit advcomp2019_ (Ping timeout: 260 seconds) |
| 01:47:29 | | Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 01:47:29 | | Quit pixelma (Quit: .) |
| 01:48:32 | | Join pixelma [0] (marianne@p4fd7f6f5.dip0.t-ipconnect.de) |
| 01:48:32 | | Join amiconn [0] (jens@p4fd7f6f5.dip0.t-ipconnect.de) |
| 01:49:33 | | Join advcomp2019_ [0] (~advcomp20@user/advcomp2019) |
| 01:53:15 | | Quit advcomp2019__ (Ping timeout: 276 seconds) |
| 03:00 |
| 03:33:16 | | Join Malinux [0] (~malin@2001:4641:4dfa::12c:c4a7) |
| 03:36:48 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:36:51 | *** | No seen item changed, no save performed. |
| 05:43:20 | | Quit PheralSparky (Read error: Connection reset by peer) |
| 07:00 |
| 07:36:52 | *** | Saving seen data "./dancer.seen" |
| 09:00 |
| 09:04:30 | speachy | Hmm, I wonder if we should modify the build clients to require a contact email address. |
| 09:05:58 | speachy | I've added an 'sdl2' target in anticipation of the UISim change. |
| 09:09:48 | speachy | _bilgus_: I'm inclined to just nuke the broken-out A-Z entries entirely from tagnavi.config |
| 09:10:05 | speachy | maybe leave a few in there commented out as examples |
| 09:11:29 | speachy | _bilgus_: https://forums.rockbox.org/index.php/topic,54557.msg254344.html#msg254344 |
| 09:11:42 | speachy | does that ring any bells? |
| 09:36:56 | *** | No seen item changed, no save performed. |
| 10:00 |
| 10:14:32 | zou_ | Hey, does the database format has changed since this page was written? Or does it seems incomplete/incorrect? https://www.rockbox.org/wiki/TagcacheDBFormat |
| 10:15:24 | speachy | gut feeling is no, but the source code is the authority |
| 10:15:25 | zou_ | I struggle understanding the index/offset thing, I can't manage to make links between entries across the different files |
| 10:17:55 | zou_ | Yes, that was my next plan if I couldn't find answers in an easier way :) I admit reading C isn't my speciality for now |
| 10:19:34 | zou_ | I'll try updating the doc if i get something is wrong there |
| 10:20:01 | speachy | thanks! |
| 10:20:39 | speachy | the general pattern with the wiki is that it's used to hash out a design, but once something is implemented/committed, the wiki tends to be neglected. |
| 10:24:10 | speachy | Hmm. In the interest of making the wiki a little more manageable, I want to start outright nuking some of the (very) obsoluete stuff. |
| 10:29:57 | zou_ | I see, in this case this page seems to have been written by a "new to all of this" (but probably less new than I am) |
| 10:30:11 | zou_ | Do you mean that this page could be considerated very obsolete? |
| 10:30:31 | speachy | starting with the various "WPS Gallery" pages that represent about 1/6th of the disk space. |
| 10:30:44 | speachy | zou_: I honestly don't know. |
| 10:31:04 | speachy | what is your goal? |
| 10:33:32 | zou_ | My goal is to write a script to import (maybe sincying later) into database my ratings from Clementine (FMPS_Rating tag, which if I understand correctly from the wiki, isn't a supported tag by Rockbox so writing some custom tagnavi rules wouldn't work?), but I might be on a xy problem |
| 10:34:05 | zou_ | Maybe my overgoal is satisfying my autistic need for understanding how all of this work :) |
| 10:35:15 | zou_ | over? hover? well meta-goal i meant |
| 10:36:07 | speachy | the DB already has a notion of "Rating" so this doesn't seem _that_ bad. One thing to keep in mind about teh database is that the on-disk format can vary on a device-to-device basis. |
| 10:36:13 | speachy | if nothig else, it uses native endianness |
| 10:36:53 | speachy | another approach is to add support for that tag to rockbox's metadata parsers. |
| 10:44:07 | zou_ | Yeah that would be an option and I would love to be able to contribute that way in projects, but seeing how my C reading skills are inefficientish, I doubt my capacities for writing good enough C parsers in less time than what I have to give to this for now, soo I think I'll stick to using custom dirty scripts for now |
| 10:44:47 | speachy | it's likely much simpler than you are thinking |
| 10:45:01 | speachy | ie these tags have to follow standard formats |
| 10:45:14 | zou_ | yeah? you mean like copy/pasting and editing tag name here and there? |
| 10:45:30 | speachy | look for the identifier, read the data, set the rating field. |
| 10:45:59 | speachy | (in a general sense. I have no idea about the specifics of this tag) |
| 10:47:02 | speachy | might be as simple as finding where the existing ID3 parser checks for known tag types anda dding this new one to the list. |
| 10:47:55 | zou_ | Yeah, I never really wrote some actual C so I always feel like I have to learn how to set a dev env and understanding building process and everything... even though understanding code logic isn't that hard |
| 10:48:50 | zou_ | Yeah I might give it a try, do you know where are those parsers defined? Is it also in tagcache.c? I'll give a look at what it look and advise |
| 10:48:50 | speachy | we've tried hard to make setting up the environments as automagic as possible; for the most part the hard stuff is figuring out the existing codebase/logic/reasons. |
| 10:49:07 | zou_ | Ok, nice :) |
| 11:00 |
| 11:35:17 | _bilgus_ | speachy I just left the A_Z stuff so we can check they work the same they appear to |
| 11:36:19 | _bilgus_ | the clip+ though I don't think I've seen this one and v_odd they say they have everal clip+ that do it, I guess I'll daily drive my clip+ for a while |
| 11:36:59 | *** | No seen item changed, no save performed. |
| 11:37:06 | _bilgus_ | weird thing is that I have none of these issues on the clipzip and they are almost literally the same except slightly less ram because the color display |
| 11:37:22 | speachy | the latter posts in that thread are on the erosqnative |
| 11:37:34 | speachy | speak to some sort of data corruption |
| 11:37:38 | _bilgus_ | the clipzip does have a potentially later rev chip |
| 11:38:02 | speachy | or maybe a stack overflow |
| 11:38:13 | speachy | (looked to be a pretty deep stack trace) |
| 11:44:13 | _bilgus_ | I don't mean to sound ungrateful or unappreciative for all the hard work the devs devoted to the Rockbox project, however all the recent playlist changes should be scrapped and the old code reverted back. The old playlist code was working fine, the new one has severe performance issues even on modern devices without any tangible advantage for the users. |
| 11:44:13 | _bilgus_ | Please, devs, don't ruin Rockbox for all of us! |
| 11:44:16 | _bilgus_ | except you do |
| 11:44:57 | speachy | yeah, I wrote what I wanted to say, erased it, and posted a very different reply. |
| 11:45:04 | _bilgus_ | lol |
| 11:46:36 | _bilgus_ | I'll switch over to the clip+ tonight and see what I can do, I find the playlist to be about on par and 3.15 is noticably laggy on the clip+ compared to now So IDK, I have seen too low of voltage to the cpu cause issues |
| 11:47:15 | _bilgus_ | but they shouldn't see that across multiple devices unless they bought them together and even then.. |
| 11:47:18 | speachy | again, the erosqnative has nothing to do with sansa voltage foibles. |
| 11:47:57 | speachy | (and then there's the matter of crappy SD cards, etc etc |
| 11:48:20 | speachy | don't go out of your way on this, I just thought it sounded vaguely familiar. |
| 11:50:47 | _bilgus_ | oh we have sluggish complaints from the clip+ wonder what his limits is set to because I'm using 20000 files in a playlist with no issue |
| 11:51:29 | speachy | modern storage sizes vastly exceed what any of these things (rockbox included) were designed to handle. |
| 11:55:16 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 11:55:17 | speachy | oh, fi you remember the opus performance bug; user just reported back that 3.14 plays things back properly. 3.15 doesn't, and dailys are better but still not up to 3.14 levels. |
| 11:55:33 | speachy | (on the old irivers) |
| 12:00 |
| 12:05:27 | speachy | I wonder if I missed anything when re-enablnig the various optimizations accidentlly removed in the pre-3.15 days |
| 12:07:31 | speachy | _bilgus_: any thoughts on my performing a few rounds of culling on teh wiki? Primairly the WPS stuff, but also the original Wiki-hosted manual and other stuff that there's zero sense in preserving. |
| 12:11:08 | _bilgus_ | hmm opus pretty sure I visited that several times now and didn't we update it to upstream too? |
| 12:11:44 | speachy | the "original" update you did just before 3.15 is what led to the perf regression on the m68k targets |
| 12:11:51 | speachy | we've updated it a bit since then |
| 12:12:01 | _bilgus_ | IDk about the wiki can we archive it or is it archived? |
| 12:12:36 | speachy | a lot of the stuff I want to archive is effectively empty "this page is obsolete" stuff |
| 12:12:44 | speachy | s/archive/delete/ |
| 12:13:14 | speachy | the page hsitory has stuff, but as a going concern the pages are useless. |
| 12:13:49 | _bilgus_ | ah we'll there were some asm tweaks in there perhaps it need to be sat down with real hardware |
| 12:14:54 | _bilgus_ | yeah useless/outdated just serves to confuse people |
| 12:15:25 | speachy | I added back in a whole lot of asm stuff that was accidentally deleted but the files in question still can't be played back in realtime |
| 12:15:42 | speachy | (it had to have been _barely_ playable before) |
| 12:16:03 | _bilgus_ | ah I remember mentioning that as we went to upstream |
| 12:16:51 | _bilgus_ | problem is 3.14 has gnarly crashes in 3.14 with some files |
| 12:17:47 | _bilgus_ | sorry opus has* |
| 12:19:21 | _bilgus_ | I'll look into the playlist stuff, I do know amachronic went a few rounds getting that stable and it is slightly slower to use playlists instead of buildig the list in ram |
| 12:20:38 | _bilgus_ | but its not terribly so and we got the ram issues figured out |
| 12:21:49 | _bilgus_ | I wonder if there is another timer firing in there that is calling up bad data after the context has already moved like for the USB stuff I found last month |
| 12:22:52 | speachy | yeah, maybe. |
| 12:23:11 | _bilgus_ | something else I discovered is that in the sim at least with logf enabled and voice enabled if I try to use the shuffle playlist it crashes |
| 12:23:51 | _bilgus_ | I might start there and maybe it will pay off for the rest |
| 12:24:50 | _bilgus_ | panic audio_reset_buffer_noalloc(): EOM (526848 > 130472)sdl_audio_callback: No Data. |
| 12:25:26 | _bilgus_ | like wtf its 380k past where the memory stops? |
| 12:41:57 | | Quit paulk (Ping timeout: 248 seconds) |
| 12:48:37 | | Join lebellium [0] (~lebellium@2a01cb0405d07f0030e6df2d20af444c.ipv6.abo.wanadoo.fr) |
| 13:00 |
| 13:06:12 | _bilgus_ | hmm on my device if I enable voice i get a crash loading the file browser I wonder if we are overflowing a buffer witht the vocie index or if its just a symptom showing because memory pressure |
| 13:06:59 | _bilgus_ | buflib_error invalid handle pin -2 |
| 13:26:42 | speachy | you should be able to compile the sim with a smaller memory limit. |
| 13:37:00 | *** | Saving seen data "./dancer.seen" |
| 13:42:31 | _bilgus_ | I have a different crash in the sim so i'll probably start there just because its a whole lot faster to iterate |
| 14:00 |
| 14:20:23 | speachy | ok, that's a lot of old crap completely cleaned out. |
| 14:31:17 | speachy | I guessimate about 3/4ths of the pages in the system are auto-created user topics |
| 14:44:00 | rb-bluebot | Build Server message: New build round started. Revision ff0ad4ca7d, 345 builds, 9 clients. |
| 14:44:01 | rb-bluebot | metadata: aac: support .aac files with mp4 container inside by Roman Artiukhin |
| 14:59:51 | rb-bluebot | Build Server message: Build round completed after 951 seconds. |
| 14:59:52 | rb-bluebot | Build Server message: Revision ff0ad4ca7d result: All green |
| 15:00 |
| 15:23:35 | | Join PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647) |
| 15:28:54 | | Quit othello7 (Ping timeout: 252 seconds) |
| 15:35:01 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 15:37:04 | *** | Saving seen data "./dancer.seen" |
| 15:37:38 | | Quit othello7 (Client Quit) |
| 15:37:55 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 15:42:10 | | Quit othello7 (Ping timeout: 248 seconds) |
| 16:00 |
| 16:54:05 | | Join jacobk [0] (~quassel@2603:8080:b200:7b02::b71) |
| 17:00 |
| 17:06:49 | | Quit jacobk (Ping timeout: 260 seconds) |
| 17:33:03 | | Quit lebellium (Quit: Leaving) |
| 17:37:08 | *** | Saving seen data "./dancer.seen" |
| 18:00 |
| 18:16:39 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 18:23:23 | | Join Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net) |
| 19:00 |
| 19:37:09 | *** | No seen item changed, no save performed. |
| 19:39:15 | | Join massiveH [0] (~massiveH@2600:4040:a982:dc00:44d6:d5a:874f:95fe) |
| 21:00 |
| 21:13:51 | | Quit othello7 (Quit: othello7) |
| 21:16:18 | | Join jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net) |
| 21:37:11 | *** | Saving seen data "./dancer.seen" |
| 21:45:59 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 21:46:05 | | Quit othello7 (Client Quit) |
| 22:00 |
| 22:18:14 | | Join othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net) |
| 22:29:08 | | Quit othello7 (Quit: othello7) |
| 23:00 |
| 23:02:17 | _bilgus_ | so far its looking like the tag cache is holding half the free ram and the playback buffer isn't able to meet its target |
| 23:03:40 | _bilgus_ | doesn't necessarily mean its the tag cache doing it its just the last core alloc max prior to it running out of ram |
| 23:37:15 | *** | Saving seen data "./dancer.seen" |
| 23:46:45 | _bilgus_ | i count 115424 bytes located so tc must be using 230 some kb |
| 23:47:53 | _bilgus_ | I do see an alloc of 18432 twice which seems oddly specific to not be the same |
icon identifies that the person is a core developer (has commit access).