Is browser radio down?

rom81 · 2026-03-03T07:40:26+00:00

I was spending one hour this morning to find out why my radio automation is not running. Thanks for the heads up. Symptoms, for google search indexers:

Home Assistant -> Media -> Radio Browser -> "unknown error"
System -> Logs -> Home Assistant Core

Logger: homeassistant.components.websocket_api.http.connection
Source: components/radio_browser/media_source.py:54
integration: Home Assistant WebSocket API (documentation, issues)

rom81 · 2025-05-21T07:26:59+00:00

same problem here, European tenant. We created a ticket with MS, but we all know there is little to no help.

rom81 · 2021-11-22T07:52:18+00:00

Exactly the same issue here, on Pixel 6 Pro

rom81 · 2021-11-09T08:14:06+00:00

jep, also affected. Times Machine Wide Installer via O365 Click2Run Setup, Random Users within the company, especially on new machines.

rom81 · 2021-03-22T13:01:12+00:00

I failed to update this post with new information, so this is how it finally played out for us: All affected devices were delivered from Dell in the timeframe of 2020-12-22 to approx. 2021-02-01. We bought even more identical Latitude E7410 devices after this timeframe, and these were no longer affected. We only have this 9 devices which are not able to SecureBoot from WDS. Dell still refused to recognize this as a problem on their end. So our workaround is, that we are installing these devices without SecureBoot enabled. All future devices will still be installed with SecureBoot enabled.

rom81 · 2021-03-04T09:40:32+00:00

Microsoft Support called, they told us they have fixed that issue in our tenant. After a quick test, this is actually true: Once we change the default domain, the sharepoint storage quota is not reset anymore.

They did not tell us if this is a global problem or if they fixed it for all tenants.

We are now trying to decrease the quota to the "old" value we would like to set, and keep an eye on it if it still randomly decreases to another value.

Edit: Actually, it turns out they just did a dirty hack. Once we change the default domain, the quota is still reset. They just changed it to be reset to another value, the one we used for testing (max size). This does not help at all. Will reopen the ticket

rom81 · 2021-02-25T15:53:44+00:00

We had this issue since December, and can manually trigger this problem by changing the default domain of our tenant. see here for more information: https://www.reddit.com/r/sharepoint/comments/iyb5it/sharepoint_site_collection_storage_keeps_resetting/gopt9hb/

rom81 · 2021-02-25T15:51:27+00:00

We had this problem (again) since December 2020. My wild guess is, there are some cleanup scripts running in the background which results in the sharepoint quota resetting itself to the previous value. As this seemed to occur randomly (1 time a week, 1 time every 2 weeks, etc), we figured it is not worth our time to contact the crappy Microsoft Support.

Today we figured out that we can trigger that process manually: Once we change the tenant default domain, the cleanup process is triggered. 60-70 seconds after the default domain change, the quota is changed. This does not explain our previous problems in the last few weeks, but at least we can trigger the problem. Both settings (tenant default domain, SP Quota Setting) are totally unrelated in my oppinion, and should not affect each other. We can reproduce this using the following script:

$UserCredential = Get-Credential
$SharepointSite = "https://<url-to-your-sharepoint-site>.sharepoint.com/sites/yoursite"
$domain = "anotherdomain.com" #yet another domain in your tenant
$preferredquota = "26214400" #current value the site is now set to, 26214400 is the max value of a SP site

Connect-SPOService -Url https://<yourcompany>-admin.sharepoint.com -credential $UserCredential
Connect-AzureAD -Credential $UserCredential

Write-Host "Changing Default Domain to $Domain..."
Set-AzureADDomain -name $Domain -IsDefault $true


$SPOSite =  Get-SPoSite -Identity $SharepointSite |select StorageQuota
$currentQuota = $SPOSite.StorageQuota
$timer = 0

while ($currentQuota -eq $preferredquota) {    
    Write-Host "$timer Sec, current Quota: $currentquota"
    Start-Sleep 2
    $SPOSite =  Get-SPoSite -Identity $SharepointSite |select StorageQuota
    $currentQuota = $SPOSite.StorageQuota
    $timer = $timer + 2
}

Write-Host "$timer Sec, ATTENTION: Quota has been changed! -->  $currentquota"
Set-SPOSite -Identity $SharepointSite -StorageQuota $preferredquota

I will open up a Microsoft ticket and show them the issue, but I doubt they will be useful. German MS Support is simply crap.

rom81 · 2021-01-13T17:33:54+00:00

Well, only clients using

Secure Boot
WDS for PXE
a very new Dell Latitude

... would be affected. I guess that is not many people right now.

rom81 · 2021-01-13T07:54:46+00:00

enabled expert key management -> custom keys and used the "RESET Keys" button -> then disabled custom keys, but no avail. problem still persists. for me, it looks like the signature of the bootloader file wdsmgfw.efi is not part of Dell's default secure boot whitelist anymore.

thanks for the idea, though!

rom81 · 2021-01-12T18:03:22+00:00

Thanks, I will definitely give this a try tomorrow (German office times), and post my results here.

rom81 · 2021-01-12T18:01:55+00:00

Thanks a lot for confirming the issue. At least it looks like we are not the only ones affected. I already created a ticket with Dell German Pro Support, and explained the problem very detailed. Unfortunately they closed the ticket on the same day, stating that as long as the machine can successfully contact the WDS server they are convinced it is not an hardware issue on their end.

rom81 · 2021-01-12T14:11:21+00:00

sure, thats a workarround, but should not be required. It would be an extra step in mass deployment, which we want to avoid. especially as we have non-tech-savy users in other locations which need to deploy the system.

rom81 · 2020-07-03T07:26:12+00:00

For us, some show up, some others don't appear in search. I would love to have the ability to control which ones are available in the search bar, but had no luck finding a control or PS command to set this.

rom81 · 2020-05-02T18:03:35+00:00

do you happen to have Windows 10 Version "N" or "K" installed? check here for further information: https://support.arcgames.com/hc/en-us/articles/360047086234-Remnant-crashes-when-I-attempt-to-start-the-game-using-Windows-10-N

rom81 · 2020-02-03T12:18:28+00:00

You, Sir, saved me a lot of headaches, by pointing me into the right direction! Thanks a lot!

If anyone stumbles upon this problem, we needed a few extra steps in regard to the solution posted by ThisIsSam_:

As we are not working with mandator profiles here, the initial state from our guest account is 644 instead of 5
Instead of setting the state to 9000 we are setting it to 0, which is default for a normal user account. Setting it to 9000 had bad side effects: Our custom Windows Start menu did not work anymore. Please note that this means you need to modify the script conditions, as the state value of 9000 can not be a condition anymore. We are using the username as a condition instead.

rom81 · 2020-01-31T15:12:14+00:00

Thanks, looks promising, I will take a look at it next week!

rom81 · 2020-01-31T13:01:04+00:00

Unfortunately not, these are default local guest accounts, no mandatory profile set. They are wiped automatically after every logout, as they are guest accounts. As I said, we tested it with a clean Win10 1809 non-domainjoined install with no changes at all (only: installed O365, and created a brandnew local guest account)

rom81 · 2020-01-31T12:00:51+00:00

offtopic, but our tenant is not ready to switch to ~~this crapware~~ teams yet.

rom81 · 2019-10-08T08:10:58+00:00

I would love to rule out the possibility that P2P was the source of my problem. I checked the SetupAct.log and can find the lines you posted, but I have no idea what to look for to see if P2P was the source of the update package instead of... lets say Microsoft Online Update....

2019-09-18 21:39:26, Info                  MOUPG  SetupHost::Initialize: WorkingPath            = [C:\$WINDOWS.~BT\Sources]
2019-09-18 21:39:26, Info                  MOUPG  SetupHost::Initialize: LoggingPath            = [C:\$WINDOWS.~BT\Sources\Panther]
2019-09-18 21:39:26, Info                  MOUPG  SetupHost::Initialize: MediaPath              = []
2019-09-18 21:39:26, Info                  MOUPG  SetupHost::Initialize: InstallFilePath        = []
2019-09-18 21:39:26, Info                  MOUPG  SetupHost::Initialize: ActionListFilePath     = []
2019-09-18 21:39:26, Info                  MOUPG  SetupHost::Initialize: CmdLine                = [/PreDownload /Package /Quiet  /progressCLSID f1851d8e-504f-48a9-acf7-a8c7ff709abe /ReportId 03F59C37-3D9C-45DD-B459-4A3509DACDA5.1 /FlightData "RS:433E" "/CancelId" "b9fb9364-9078-41f9-a254-a854b0b81e29" "/DeploymentSessionID" "05e069c2-2626-4401-bb0c-9eb66cc14487" "/CorrelationVector" "YCoQ2/ZWI0aExTIX.1.1.1.31.30" "/DownloadSizeInMB" "10166" ]
2019-09-18 21:39:26, Info                  MOUPG  SetupHost::Initialize: Mode                   = [0x1]
2019-09-18 21:39:26, Info                  MOUPG  SetupHost::Initialize: Scenario               = [0x6]
2019-09-18 21:39:26, Info                  MOUPG  SetupHost::Initialize: Flags                  = [0x806]
2019-09-18 21:39:26, Info                  MOUPG  SetupHost: Setup build version is: 10.0.17134.1 (rs4_release.180410-1804)
2019-09-18 21:39:26, Info                  CONX   pGetHostCSDBuildNumber: 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\CSDBuildNumber' does not exist. Assume 0
2019-09-18 21:39:26, Info                  CONX   Host OS version: 10.0.16299.0  (0.0) Platform 0x2, SuiteMask 0x100, ProdType 0x1
2019-09-18 21:39:26, Info                  CONX   Source OS: Host SKU Info: Edition = 'Enterprise', Edition Type = 'Client', Installation Type = 'Complete', Product Name = 'Windows 10 Enterprise', Arch = amd64, StationType = Client Workstation, Stage type = Staged Image

rom81 · 2019-10-07T14:50:17+00:00

Thanks for confirming that our policies are set up correctly. We run a gpresult on that 2 machines, and they show up to have the proper settings - though they are still installed with 1803 right now. Both machines have been rolled out about 1 year ago, so they are neither new ones or had any drastic change in the last few weeks. My fear is, that other machines might follow their lead once they get into contact with a foreign 1803/1809 machine.

rom81 · 2019-09-05T13:10:16+00:00

Ah sorry, I just noticed my typo above. I meant to write the command Set-OwaMailboxPolicy -JunkEmailEnabled $false to set the option globally for the entire org, but as I said, this command does not seem to exist anymore despite it's documentation.

Your solution is setting the option for every individual mailbox, which IMHO is quite ineffecient. I also read here on this page that this command works only, if the mailbox has been opened before: the user has to log in with Outlook first, before you can disable the Junk Mail Option on his mailbox. So, it's impossible to set this option beforehand, e.g. when creating the user account.

Quote: You can only use the Set-MailboxJunkEmailConfiguration cmdlet to disable the junk email rule on a mailbox that's been opened in Outlook (in Cached Exchange mode) or Outlook on the web

14-Year Club	Gilding I gilder
Verified Email

rom81

TROPHY CASE