generate valid cue files from a playlist
uses remarks to store extra id3 info and display and playlist index
Change-Id: I00c9f6389445bb601dde6eb8f36157044024f8cb
This keeps rbutil from being confused.
When a new release happens, all of this automagically fixes itself!
Change-Id: I15e3ebb5e274638b9b88f670ce53f950061e9044
* If CF Timing mode is specified, treat it as SSD
(some SD adapters don't report CFA supported but but report this,
and _all_ microdrives seen do not report this)
* If CFA compliant and CF power level 0, treat as SSD
Change-Id: Ia8c88b4636af9bae75fbd1c253d8b2b01bca6584
The SSD detection heuristic is flawed, and when it fails
(due to very crappy CF->SD adapters) we end up corrupting things.
So let's give up a slight amount of performance on the original hard
drives (which are aging out anyway) in favor of guaranteeing safety.
Change-Id: Id92583a6b9ae6ec543b91b3e0f8f28b57ac38cb0
A set of new tags for themes that allow them to display a quickscreen item's name or value like what is displayed on the default quickscreen.
There are 8 tags in total, 2 for each direction or "item".
One type of tag displays the setting name, while the other displays the setting's value.
All tags output an "ERR" string if no valid setting is found for that item.
Quickscreen Item name tags: %QT, %QR, %QB and %QL.
Quickscreen Item value tags: %Qt, %Qr, %Qb and %Ql.
Change-Id: Ia08ba5940e38065e051a0aefa2cff142c9e58684
reading the disk works fine for on disk playlist but
trying to read from the disk with the current playlist
becomes unbearably slow
removes the static playlist_track_info prefering the unused one
already on the stack from search_playlist()
Change-Id: I01b836b4fe46bb51ef6a28d5db6b3f9cdc7d1e51
...Instead of renaming it to include the player name and version. This
was the _only_ build artifact treated that way, and I can't find an
explanation of why.
Change-Id: I13f1a43ddc1f2ac3183f57892cf068e8ed16f37d
the extra title pointer and alignment adds around 1k to the bss area
since we already have a pointer to track->name we can just save an offset
for the title data
Change-Id: I3a19857631d70276134bcc97940824a3e2f80e4a
Was accidently disabled in 14c6bb798d
(in January 2019)
(Had to make a minor change due argument differences)
Change-Id: If7c128cdeaa9ed82b2b33de1b75ca7cc4a95abdd
Not sure this is a great idea from disk and battery standpoint
but there is no reason you can't..
using the name buffer to fill title data
prevent hitting the disk for each screen scroll
add get_metadata_ex to allow flags
METADATA_EXCLUDE_ID3_PATH
prevent copying the filename to the ID3 struct
METADATA_CLOSE_FD_ON_EXIT
instead of seeking to the beginning the file is closed before
get_metadata returns
add logic to allow a invalid fd to signal that get_metadata
should open and close the file within its call
bugfix per Chris_s don't use the tagcache for the trackinfo
Change-Id: Ic7a595b39a8d7a57f975312bc9c8bb4111f22a88
* hostfs_removeable()/present() needed IF_MDVOID() in their prototypes
* SIM_EXT_INSERTED/EXTRACTED are gated by HAVE_HOTSWAP
Change-Id: Id8c688f3538db99586a4f5062c83466374451883
* xDuoo X3 fix some warnings due to an incorrect #ifdef
* stub storage_removeable() and storage_present() for non-HOTSWAP builds
* sim_trigger_external() is gated by HOTSWAP, not MULTIDRIVE
Change-Id: I38f14fdfeba13957899c378051d49afc2e8245e5
