PeteL

Yes, I think it would be possible. Although designating archive folder (with sub folders) it's more feasible. I thought about it before. I have some archived shows that should be stored in different location. Thanks for the suggestion.

Try different browsers and see if problem persists. Reload WebUI by clicking keyboard buttons on Windows machine Control + F5 and on Mac Shift + Reload icon in the top bar Click F12 on your keyboard to open web dev panel and look for any errors in Console tab One more thing. 404 error. Wich pne applies: You cannot connect to WebUI at all and browser throws 404 error You can connect to WebUI but instead of seeing Home page you see 404 error

Hi. I'm glad you enjoying the app. I'm not sure if I used rss validator, however when I created rss feeds they were set to be compatible with Apple devices. I looked at YouTube Music podcast section on my iPhone. How do you add rss feed to this app? From what I understand YT Music is just a shell for content available on regular YT. Can you provide sample rss feed that works for you? Since you are using Cloudflare tunnel you could open rRadio on your phone browser and stream it this way too. The app scales to the phone screen.

I'm glad you are enjoying the app. Paypal donate button worked initially but for some reason Paypal requires right now to convert personal account to business account for some reason. I'm not interested in doing this. I consider rRadio to be my personal project therefore I'm not planning to make git repository to be available to public. I have still some ideas for further development and I welcome any suggestions too.

I apologize, somehow I missed this question. On your phone, in the web browser navigate to http://your.server.ip:port/rradio Go to Feeds page Select link for show you want to add to podcast app Press on show link and hold for couple seconds Small menu will show up. Select option Copy link In podcast app there should be an option to add url manually Paste copied link Show feed should be added to your podcast app rRadio creates and updates feeds every time new recording is added You can also trigger creating feeds by clicking on icon Reload Feeds at the top of the Feeds page

The first code 137 happens when recording is canceled manually. I'm not sure why would FFMPEG send this code when signal is dropped Please take a screenshots of the scheduled jobs. Also, please provide URL of the station that gives you problem. I would like to test it. It seems that somethings has changed if you experience the same problems across various stations. Tell me more about your setup. I recommend /config directory to be stored on cache drive. /mnt/cache/appdata/rradio

Do you see any exit code for this job on Jobs page in the recording log? Do you experience the same signal dropouts for other radio stations? Did this job ever recorded properly in this version of rRadio 2.0.1 ? I do get some signal disconnections from time to time. There could be different reasons for loss of signal. Maybe you can find different URL for that station. You can still use previous version of the app. To do that you need to pull image with following tag docker pull mpcdigitize/rradio:build-2503

New release is available version 2.0.1 build 25.05 Additions:Direct Stream --> Mp3 Scheduling recording has new bitrate option that allows saving stream to MP3 without re-encoding. Source URL must be in MP3 format. Sources that are in other formats like AAC of FLAC will be re-encoded to MP3 with default bitrate 128kbps. Settings page containes option for scheduling database maintenance Updated Hangfire to version 1.8.18 Removed duplicate ffmpeg -c flag

I didn't notice that -c flag was used more than once. Thank you for pointing this out. I think preserving original stream without re-encoding is possible. I did some test already with FLAC output. Potential problem is that some users may not know what stream format is being used. It may also cause some compatibility issues with some web browsers. Anyway I think this feature can be implemented.

It’s been a long time since the first release of the rRadio. I’ve been working on new features and improvements and finally I think it is ready to be released into the wild. There are some major changes that would make application easier and more enjoyable to use it. Let me highlight some of the things that are included in this release. * All the recordings are divided right now into two categories Added and Played. Accessing previously played shows is a breeze. Bear in mind that playing recording will not prevent deleting it when its default Keep value expires. * To prevent deletion there are two options. First is adding recording to Favorites and second is adding it to Archive. When file is added to Archive it will only be accessible through Archive. This is a great feature if you want to preserve some recordings * Job scheduler has a new feature One-Time recordings. It’s possible to set recording for specific date, but it’s also possible to set recordings for different dates and group them. Fo this to happen, we need to create different One-Time jobs with the same name. * New Activity page displays progress of jobs that are being currently recorded. In addition Upcoming tab shows queued jobs for Today and Tomorrow. Please note that scheduled recording times are displayed in user’s Time Zone local time * Support for different Time Zones. No more calculating time offsets between different Time Zones is required. Set Radio Station Time Zone and use its local time to schedule recordings. Great benefit of this approach is the we do not have to worry about adjusting jobs to Daylight Saving Time. If you have already existing Sources and Jobs, you have to change Time Zone and adjust manually scheduled jobs to local time of that Time Zone. This is not done automatically. * Jobs page has new actions too. Job can be suspended if for some reason we do not want record it right now. Also, job can be triggered. The feature should be used for testing purposes only if we want to find out if scheduled job would run properly. It will not in any way affect saved scheduled job. * Settings page. I understand that date format was annoying for some the users. Now you can select your preferred format. This would apply to future recordings, but new Maintenance page has a button that would allow renaming all existing titles. Depending on how many recordings are present in your database it may take few seconds. Please be patient. * Maintenance page contains buttons that initiate database related activities. Every once a while station’s URL may go rogue. It’s possible right now to look for failed URLs. * I have to say I got little bit bored looking at the default colors of the application. I included 15 more additional Color Themes that can be selected in Settings page. My favorite right now is Chinese Violet. * For new users that will use application for the very first time. They will be taken directly to the page where they have to setup new source radio station. * Since this is an update, WebUI may experience some odd behavior. There are new script and elements that did not exist before. Please use on your keyboard Ctrl+F5 keys to reload page’s resources. This applies to browsers on Windows machines. On Mac, you should hold Shift button and click reload icon on top next to previous and next page buttons. * There are numerous bug fixes and improvements. I’ve been beta testing application for last 3 months working diligently on squashing them and I think we are ready to use new version of rRadio.

1. If you look at the log you can see the container internal Time Zone 2024-12-04 07:15:41 [TIME_ZONE] (UTC+01:00) GMT+01:00 2024-12-04 07:15:41 [INFO] (Checking database) It's possible to set the time zone by including additional ENV variable in container template. There was someone else with the same issue. Please refer to the earlier posts on how to do it. 2. 2024-12-04 07:20:12 [INFO] (Arguments: -i "{URLHERE}" -c copy -t 73800 -metadata Title="{TITLEHERE} wed (12.04.24 Wed. 19:20)" -metadata Album="{TITLEHERE} wed" -metadata Artist="{RADIONAME}" -metadata Track="1204" -metadata Album_Artist="{RADIONAME}" -metadata Year="2024" -metadata Genre="Radio" -metadata Comments="{TITLEHERE}_wed_(2024-12-04_19.20.12_Wednesday)" -c:a libmp3lame -ab 320k -y "/app/config/temp/{TILTEHERE}_wed_(2024-12-04_19.20.12_Wednesday).mp3".) -t 73800 is over 20Hrs of recording time. I strongly recommend not to do that, considering also thet your selected bitrate is 320kbps. This will result in extremely large file 3. 2024-12-04 11:05:10 [INFO] (Executing job 1-1) 2024-12-04 11:05:10 [INFO] (Job registered: True.) 2024-12-04 11:05:10 [INFO] (Aborting) The first attempt was aborted because the job with the same name & time was already executed. To prevent creating duplicate recordings, scheduler is configured to to run recurring job only once a day. 4. {RADIONAME} I'm confused about this naming. I think you edited the log output. If not than I would not use any parenthesis. These tags are written into a file. I'm not sure how ffmpeg is treating them 5. Recordings logs are empty. There is a bug in the software. It will be rectified in upcoming release Please tell me more about your setup. Are you running it on Unraid? Is appdata stored on cache drive? Please post a screenshot of the job you scheduled.

I never came across such a behavior. This is highly unusual. Please confirm what settings did you use for this particular job. Continuous option would create one single file for entire scheduled duration. It will not continue recording past the scheduled duration. Hourly will attempt to record scheduled job in segments. Example if you schedule 3 hours recording starting from 8 AM then this job will be triggered 3 times at 8AM., 9AM and 10AM. hence you will have 3 hourly mp3 files. To verify what parameters were sent to ffmpeg you can open container log. You will see details of the triggered job. If you think something is going on with currently recorded file, you can stop container. This will force ffmpeg to stop

1. I suggest you navigate to myipaddress:port/dashboard/recurring to see when is the next time this job will be triggered. You can also verify if job is set according to your time zone. 2. If I understand correctly you are trying stream live radio link through proxy/vpn wireguard. I have setup my radio container to be accessed using Nginx Proxy Manager and Cloudflare and I have no issues streaming it live on my phone. If the url that you are using has signal and can be recorded than there is nothing that would prevent it from being streamed. If I'm at work, I cannot stream or played recorded files at all. This is because of the security measure put in place by my employer. My guess is your issues are related to the proxy server. 3. I'm not familiar with wireguard. Most likely you have to do some port forwarding on your router 4. There is no additional settings that are required. Url is simply passed to a browser for playback

The way you have set it up is that appdata is using two locations. Primary location is cache drive and secondary location is an array. Most likely you have files residing in both cache/appdata and disk#/appadata What you really want is appdata to be exclusively on cache drive In addition docker image should be outside of an array too as Unraid constantly calculates parity

You can make this changes when you setup container template. Config folder can be set either to appdata on cache drive or in the array. You can edit location. From my own experience I can tell you that you will get better performance when appdata is outside of an array. Maybe create another share on cache called appdata1 and select it for config folder when installing cointainer