To improve startup robustness, the application now performs hostname resolution in a separate thread using pthread. Instead of exiting if the initial resolution fails, it will now retry periodically in the background until successful. This ensures the client remains resilient to temporary network connectivity issues during initialization.

Updated the station selection logic to use station names instead of numeric indices when interacting with the dialog list. This change ensures consistent identification of saved stations even if the order or list contents change, making the interface more robust for the user.

Added logic to playit to inspect URLs for known codec signatures when a codec isn't explicitly provided, falling back to a more intelligent player selection. This includes support for reading the first few bytes of playlist files (.m3u, .pls) to detect the embedded codec and choose the most appropriate playback command. This change ensures better compatibility and player assignment for a wider variety of stream types.

Resolved a bug where the 'Now Playing' status was being misassigned when stations were launched automatically via command line arguments. By updating the nowplaying index to correctly match the favorite station number instead of an uninitialized variable, users will now see the correct station information displayed upon startup. This ensures a smoother initial experience for power users leveraging automated playback.

This change bumps the user agent sent by libcurl from ziptuner/0.4 to ziptuner/0.5, keeping network requests aligned with the current release version. It doesn’t change runtime behavior directly, but it improves version visibility in logs, server-side diagnostics, and any tooling that inspects client metadata. The practical effect is cleaner identification of 0.5 clients in the wild.

This patch tightens the favorite/autoplay logic in ziptuner by changing how the current favorite index is tracked, persisting the selected station directly to ziptuner.fav, and avoiding a cross-filesystem rename path that was failing on IZ2S. It also fixes cleanup behavior so deleting the currently autoloaded favorite removes the resume marker instead of leaving stale state behind, and updates startup checks so autoplay only triggers for a valid saved favorite. The example VLC launcher now reflects that behavior more clearly with a prompt to resume the saved favorite. Practical effect: favorite station resume should be much more reliable now.

The VLC example launcher now checks for an existing ziptuner.fav file and shows a simple dialog prompt asking whether playback should resume automatically. If the user accepts, the script passes -a through to ziptuner; otherwise it starts normally. This makes the example script friendlier for repeat use without forcing autoplay every time, so restarting the tuner is a bit smoother.

This change tightens the autoplay logic around favorites by validating the requested favorite number before trying to play it, which avoids invalid index handling when -a is used. It also stops deleting ziptuner.fav during the favorites flow, so saved state is retained more consistently across stop/rerun behavior, and removes an unnecessary cleanup of ziptuner.item when returning from favorites. There are also minor housekeeping updates like a user-agent version bump and debug guard cleanup. In practice, autoplay from favorites should behave more reliably and keep the expected station state intact.

This change removes always-on debug paths and wraps the diagnostic file dumps in #ifdef DEBUG, so normal builds no longer carry extra debug behavior unless it’s explicitly enabled. It also replaces the NEW_API flag with #ifndef OLD_API, making the newer Radio Browser API the default while still preserving compatibility with the legacy path when needed. The result is a tidier configuration model and less accidental debug noise in everyday use.

This change fixes a small but user-visible state bug in ziptuner.c: when switching from a search menu into favorites, the code could reuse previtem from the earlier search context. The update explicitly clears previtem before favorites handling, then sets it only from favnum when a favorite should actually be played. In practice, favorites navigation and autoplay should now behave consistently instead of inheriting the wrong prior selection.

This change makes HTTPS access more flexible by turning certificate verification bypass into an explicit runtime option instead of hardcoding it for specific builds. In do_curl, certificate handling now uses a skipcert flag, IZ2S can point curl at a known CA bundle path when verification is enabled, and the CLI/parser/help text were updated to support -k. The commit also enables the newer radio-browser API and tightens dialog exit-code handling, so the practical effect is that ziptuner should work more reliably across older or unusual Linux environments without forcing insecure defaults for everyone.

This change introduces a small wrapper around system() for dialog invocations and routes the main interactive code paths through it. The wrapper detects dialog exit codes for ESC and Ctrl-C, then calls the existing quit() path so interactive cancellation behaves predictably across station selection, search, favorites, and startup dialogs. It also appears to disable the NEW_API compile flag in this commit, but the main user-facing improvement is cleaner interruption handling during terminal UI flows. Practical effect: users can back out with ESC/Ctrl-C and the app exits cleanly instead of leaving awkward state behind.

This change switches the new Radio Browser path over to a dedicated server variable and persists resumed searches in a separate request file so old and new API formats don’t collide. It also threads the selected server through search, metadata, and playlist URL generation, which is important now that the new API recommends using randomized hosts and HTTPS-only endpoints. The result is a safer migration path for the incompatible API without breaking the ability to resume previous searches.

This change tweaks the splash screen minimum height from 25 to 24 lines so the UI fits the Zipit display more cleanly, and it introduces a new NEW_API code path that resolves all.api.radio-browser.info and picks a random recommended backend server. The API host is now selected earlier in startup instead of only during search setup, which should make network interactions more consistent and better aligned with the newer Radio Browser infrastructure. In practice, Zipit gets a slightly better-fitting screen layout and the app should connect to the radio API more robustly.

This change adds conditional support for the newer Radio Browser API, including updated station IDs, bitrate parsing, endpoint URLs, and category lookups for countries, languages, and tags. It also improves runtime behavior by ignoring SIGPIPE, persisting the last curl/search/play commands for reuse and debugging, and clearing the terminal cleanly through a shared quit path instead of exiting abruptly. The result is better compatibility with current radio data sources and fewer frustrating crashes or messy terminal states when using the app.

This change addresses breakage in radio search and playlist retrieval by switching requests back from the newer api.radio-browser host to the older www.radio-browser endpoints for now. It also fixes resume-search behavior by saving the active search URL at the point where a valid JSON result set is returned, and updates curl requests to identify the client as ziptuner/0.2 instead of the default sample agent. The net effect is a more reliable search flow while the newer Radio Browser API migration is still being worked out.

This change adds an explicit note in ziptuner.c about upstream Radio Browser API changes, including the move from id to UUID-based fields and country to countrycode, so the remaining integration work is easier to track. In the meantime, the playlist URL is pointed back at www.radio-browser.info instead of api.radio-browser.info because the newer endpoint was returning redirects and breaking station resolution. Practically, this is a small but important stopgap that should keep playlist fetching working while the client is updated for the new API.