10 Nov 2017

Il caso #ovhdown

La giornata del 9 novembre 2017 verrà ricordata da noi di Newradio e da molti operatori del settore come una delle più nere degli ultimi anni. Alle ore 7.14 del mattino ogni sistema di allarme della nostra azienda incomincia a suonare: nel giro di pochi secondi tutta la nostra struttura server fisica e cloud non è più raggiungibile ovunque. Subito ci accorgiamo che dipende dal nostro fornitore partner OVH che dichiara un grave incidente elettrico nella regione di Strasburgo dove sono presenti tutti i server della nostra piattaforma di streaming. In primis reagiamo con tranquillità pensando che la situazione sia momentanea e velocissima nella ripresa.  Scopriamo invece che il danno è più grave di quanto si pensasse e quindi i servizi sarebbero tornati online con tempi ben più lunghi della previsto. Ma poichè la legge di Murphy è sempre dietro l’angolo, come se non bastasse alle ore 8.15 anche i datacenter di Rubaix vanno inesorabilmente giù, questa volta a causa di un problema sulla rete in fibra ottica di collegamento tra i datacenter. Insomma un buio totale che colpisce oltre 50.000 servers, migliaia di servizi e oltre un milione di siti web in Europa.

L’azienda OVH, leader in Europa, decide di comunicare lo stato di avanzamento dei lavori in modo molto semplice ed efficace: Octave Klaba, CEO e fondatore di OVH utilizza il suo account twitter per informare tutti i clienti OVH sull’andamento delle operazioni.

Alle ore 10.37 il guasto a Rubaix viene risolto completamente mentre bisognerà aspettare oltre le ore 11.15 per ripristinare le line elettriche sui datacenter di Strasburgo. Tornata l’elettricità incomincia la lunga lavorazione del ripristino di tutti i servizi che devono essere riaccesi uno per uno e controllati nelle loro funzionalità. Questa operazione necessita di ulteriore tempo e quindi i servizi non sono tornati disponibili tutti subito ma gradualmente nell’arco dell’intera giornata. Per quanto ci riguarda tutti i servizi (tranne una sola istanza MBCloud) sono tornati disponibili entro le ore 16.00.

Sinceramente non ce la sentiamo di essere polemici su questo grave disservizio, anche se alcune responsabilità ci sono e lo stesso Octave Klaba, in un comunicato di questa mattina, ha comunque fatto un ‘Mea Culpa’ riguardo ad alcuni errori fatti negli anni nella progettazione di alcuni datacenter di Strasburgo. Preferiamo invece fare comunque un plauso all’azienda OVH per come abbia reagito in tempi velocissimi per risolvere una problematica di tale portata. Non so quante aziende sarebbero riuscite a rialzare un DOWN di ben 7 datacenter in poco più di 3 ore. Certamente ora l’azienda OVH dovrà lavorare sodo per risolvere i punti deboli riscontrati ieri e fare in modo che una situazione del genere non si debba più ripetere con dimensioni del genere.

Un plauso va anche a tutte le migliaia di clienti Newradio che sono stati impattati dal disservizio di ieri che hanno capito la situazione e hanno atteso con calma la risoluzione e seguito tutte le informazioni in merito sulle nostre pagine Facebook e twitter (anche perchè pure il nostro sito aziendale era completamente irraggiungibile).

Di seguito un po di documentazione ufficiale dell’accaduto direttamente dalle comunicazioni ufficiali del CEO di OVH  Octave Klaba:

Riguardo all’incidente di Strasburgo (comunicazione del 10 novembre mattina):

Ciao,
Ieri mattina alle 7:23 abbiamo avuto un’interruzione importante nel nostro sito di Strasburgo (SBG): un’interruzione dell’alimentazione che ha lasciato tre datacenter senza alimentazione per 3,5 ore. SBG1, SBG2 e SBG4 sono stati influenzati. Questo è probabilmente il caso peggiore che ci sarebbe potuto accadere.

Il sito SBG è alimentato da una linea elettrica da 20 KVA composta da 2 cavi ciascuno fornendo 10MVA. I 2 cavi lavorano insieme e sono collegati alla stessa sorgente e allo stesso interruttore dell’ELD (Strasbourg Electricity Networks). Ieri mattina, uno dei due cavi è stato danneggiato e l’interruttore ha interrotto l’alimentazione al datacenter.

Il sito SBG è stato progettato per funzionare, senza limiti di tempo, sui generatori. Per SBG1 e SBG4, abbiamo creato un primo sistema di backup di 2 generatori di 2MVA ciascuno, configurati in N + 1 e 20kv. Per SBG2, abbiamo creato 3 gruppi in configurazione N + 1 1.4 MVA ciascuno. In caso di guasto esterno, le celle ad alta tensione vengono riconfigurate automaticamente da un sistema di failover motorizzato. In meno di 30 secondi, i datacenter SBG1, SBG2 e SBG4 possono avere una potenza ripristinata di 20kv. Per effettuare questo passaggio senza tagliare i potenziali server, abbiamo un alimentatore ininterrotto (UPS) in grado di mantenere l’alimentazione per un massimo di 8 minuti.

Ieri mattina, il sistema di failover motorizzato non ha funzionato come previsto. Il comando per l’avvio dei generatori di backup non è stato fornito dal NSM. Si tratta di un NSM (motorizzazione normale di emergenza) fornito dal fornitore delle celle ad alta tensione a 20KV. Siamo in contatto con la fabbricazione / suplier per comprendere l’origine di questo problema. Tuttavia, questo è un difetto che dovrebbe essere stato rilevato durante i test periodici di simulazione di guasti sulla sorgente esterna. L’ultimo test di SBG per il recupero di backup era alla fine di maggio 2017. Durante questo ultimo test abbiamo alimentato SBG solo dai generatori per 8 ore senza problemi e ogni mese testemo i generatori di backup senza alcun costo. E nonostante tutto, questo sistema non era sufficiente per evitare la sconfitta di ieri.

Intorno alle 10, siamo riusciti a passare manualmente le celle e cominciarono a alimentare nuovamente il datacenter dai generatori. Abbiamo chiesto a ELD di scollegare il cavo difettoso dalle celle ad alta tensione e di accendere nuovamente l’interruttore con solo 1 dei due cavi e quindi sono stati limitati a 10MVA. Questa azione è stata eseguita da ELD e la completa alimentazione è stata ripristinata alle ore 10:30. I router SBG sono tornati online da 10:58 in poi.

Da allora, abbiamo lavorato per riavviare i servizi. L’accensione del sito con l’energia consente di riavviare i server, ma i servizi in esecuzione sui server devono ancora essere riavviati. Ecco perché ogni servizio è tornato gradualmente dalle 10:30. Il nostro sistema di monitoraggio ci permette di conoscere l’elenco dei server che hanno avviato correttamente e quelli che hanno ancora un problema. Interveniamo su ciascuno di questi server per individuare e risolvere il problema che impedisce il riavvio.


Alle 7:50, abbiamo creato un’unità di crisi in RBX, dove abbiamo centralizzato le informazioni e le azioni di tutte le diverse squadre coinvolte. Un camion di RBX è stato caricato con pezzi di ricambio per SBG. È arrivato alla sua destinazione intorno alle 17:30. Per aiutare le nostre squadre locali, abbiamo inviato squadre dal datacenter LIM che si trova in Germania e personale dal centro dati RBX, tutti mobilitati in loco a partire dalle 16:00.

Per evitare scenari catastrofici come questo, negli ultimi 18 anni, OVH ha sviluppato architetture elettriche che possono resistere a tutti i tipi di interruzioni di corrente. Ogni prova, ogni difetto, ogni nuova idea ha arricchito la nostra esperienza permettendoci di costruire oggi datacentre affidabili.

Allora perché questo fallimento? Perché SBG non ha resistito a un semplice fallimento elettrico? Perché non sapeva che tutta l’intelligenza che abbiamo sviluppato in OVH, impedisca questa catastrofe?

La risposta rapida: la griglia elettrica di SBG ha ereditato tutti i difetti di progettazione che erano il risultato delle piccole ambizioni inizialmente previste per quella posizione.

Ora ecco la lunga risposta:

Nel 2011, abbiamo pianificato l’implementazione di nuovi data center in Europa. Per testare l’appetito per ogni mercato, con nuove città e nuovi paesi, abbiamo inventato una nuova tecnologia di implementazione del datacenter. Con l’aiuto di questa tecnologia sviluppata internamente, speriamo di ottenere la flessibilità che viene fornita con l’implementazione di un data center senza i vincoli di tempo associati ai permessi di costruzione. In origine volevamo l’opportunità di convalidare le nostre ipotesi prima di effettuare investimenti sostanziali in una determinata località.

Così, all’inizio del 2012, abbiamo lanciato il datacenter SBG1 fatto con conteiner navali. Abbiamo distribuito 8 conteiner e SBG1 è stato operativo in meno di 2 mesi. Grazie a questa implementazione ultra-veloce che ha impiegato meno di 6 mesi abbiamo potuto confermare che SBG è in realtà una posizione strategica per l’OVH. Entro la fine del 2012 abbiamo deciso di costruire SBG2 e nel 2016 abbiamo lanciato la costruzione di SBG3. Questi due datacenter non sono stati costruiti con conteiner, ma erano basati sulla nostra tecnologia “Tower”. La costruzione di SBG2 ha avuto 9 mesi e SBG3 sarà messo in produzione entro un mese. Al fine di affrontare la questione dello spazio, all’inizio del 2013 abbiamo costruito SBG4 molto rapidamente, basandosi nuovamente sul sistema a conteiner.

Il problema era che, implementando SBG1 con la tecnologia basata su conteiner, non siamo riusciti a preparare il sito per un progetto su vasta scala.

Abbiamo fatto 2 errori:

1) Non abbiamo fatto il sito SBG conforme agli standard interni che richiedono 2 alimentatori elettrici separati da 20KV, proprio come tutte le nostre posizioni DC, dotate di doppie alimentazioni elettriche. Si tratta di un investimento importante di circa 2 a 3 milioni di euro per alimentazione elettrica, ma riteniamo che questo fa parte del nostro standard interno.

2) Abbiamo costruito la griglia elettrica di SBG2 collocandola sulla rete elettrica di SBG1 invece di renderli indipendenti l’uno dall’altro, come in tutti i nostri data center. A OVH, ogni numero del datacenter indica che la griglia di alimentazione è indipendente da altri datacenter. Ovunque tranne il sito SBG.

La tecnologia basata su conteiner è stata utilizzata solo per costruire SBG1 e SBG4. Di fatto, abbiamo capito che il data center a conteiner non si adatta alle esigenze del nostro mercato. Sulla base del tasso di crescita di SBG, la dimensione minima di un sito deve essere uguale a diversi datacenter e quindi una capacità totale di 200.000 server. Ecco perché per implementare oggi un nuovo data center, utilizziamo solo due tipi di progetti che sono stati ampiamente testati e progettati per progetti e affidabilità su larga scala:

1) la costruzione di torri da 5 a 6 piani (RBX4, SBG2-3, BHS1-2), per 40.000 server.
2) l’acquisto di edifici (RBX1-3,5-7, P19, GRA1-2, LIM1, ERI1, WAW1, BHS3-7, VIH1, HIL1) per 40.000 o 80.000 server.

Anche se l’incidente di ieri mattina è stata causata da un automa di terze parti, non possiamo negare la nostra responsabilità per la ripartizione. Abbiamo un po ‘di presa su SBP per raggiungere lo stesso livello di standard di altri siti OVH.

Nel corso del pomeriggio abbiamo deciso il seguente piano d’azione:
1) l’installazione di un secondo alimentatore elettrico 20MVA completamente separato;
2) separare la griglia elettrica SBG2 da SBG1 / SBG4, nonché la separazione del futuro SBG3 da SBG2 e SBG1 / SBG4;
3) migrazione dei clienti SBG1 / SBG4 a SBG3;
4) chiusura SBG1 / SBG4 e disinstallazione dei conteiner.

Si tratta di un piano di investimento di 4-5 milioni di euro che lanceremo domani e la speranza ci permetterà di ripristinare la fiducia dei nostri clienti in SBG e OVH.
Siamo profondamente dispiaciuti per questo incidente e ringraziamo la fiducia che ci metti in noi.

saluti,
Octave.

Riguardo all’incidente di Rubaix (comunicazione di ieri 9 novembre):

Caro cliente,
Questa mattina abbiamo sperimentato un incidente sulla rete ottica che collega il nostro sito Roubaix (RBX) con 6 dei 33 punti di presenza (POP) nella nostra rete. Parigi (TH2 e GSW), Francoforte (FRA), Amsterdam (AMS), Londra (LDN), Brussle (BRU).
Il sito di Roubaix è connesso tramite 6 cavi a fibre ottiche a questi 6 POP: 2x RBX <> BRU, 2x RBX <> LDN, 2x RBX <> (1x RBX <> TH2 e 1x RBX <> GSW). Questi 6 cavi in ​​fibra ottica sono collegati ad un sistema di nodi ottici, il che significa che ogni cavo ottico in fibra ottica può trasportare 80 x 100 Gbps.
Per ogni 100 G collegato ai router, utilizziamo due percorsi ottici che si trovano in posizioni geografiche distinte. Se viene tagliato qualsiasi collegamento in fibra ottica, il sistema riconfigura in 50 ms e tutti i collegamenti restano UP.
Per connettere RBX ai nostri POP, abbiamo la capacità di 4.4Tbps, 44x100G: 12x 100G a Parigi, 8x100G a Londra, 2x100G a Bruxelles, 8x100G a Amsterdam, 10x100G a Francoforte, 2x100G alla GRA DC e 2x100G a SBG DC.

Alle 8:01, tutti i link 100G, 44x 100G, sono stati persi in una sola volta. Dato che abbiamo un sistema di ridondanza in atto, la radice del problema non potrebbe essere l’arresto fisico di 6 fibre ottiche contemporaneamente. Non potevamo fare una diagnostica remota del telaio perché le interfacce di gestione non funzionavano. Dovevamo intervenire direttamente nelle stanze di routing, per risolvere il telaio: scollegare i cavi tra il telaio e riavviare il sistema e infine fare la diagnostica con il produttore di apparecchiature. I tentativi di riavviare il sistema richiedevano molto tempo perché ogni telaio richiede 10-12 minuti per avviarsi. Questa è la ragione principale per cui l’incidente è durato così a lungo.

Diagnostica: tutte le schede di interfaccia che usiamo, ncs2k-400g-lk9, ncs2k-200g-cklc, sono state avviate in modalità standby. Ciò potrebbe essere dovuto a una perdita di configurazione. Abbiamo quindi recuperato il backup e ripristinato la configurazione, che ha permesso al sistema di riconfigurare tutte le schede di interfaccia. I 100G nei router sono tornati naturalmente e la connessione RBX ai 6 POP è stata ripristinata alle 10:34.

C’è chiaramente un bug software sull’apparecchiatura ottica. Il database con la configurazione viene salvato 3 volte e copiato su 2 schede di monitoraggio. Nonostante tutte queste misure di sicurezza, il database è scomparso. Lavoreremo con l’OEM per trovare la fonte del problema e contribuire a risolvere il problema. Non dubitiamo il produttore di apparecchiature, anche se questo tipo di bug è particolarmente critico. Uptime è una questione di design che deve considerare ogni eventualità, anche quando non funziona nient’altro. OVH deve assicurarsi di essere ancora più paranoico di quanto già in ogni sistema che progetta.

I bug possono esistere, ma gli incidenti che incidono sui nostri clienti non sono accettabili. Questo è un problema OVH, perché nonostante tutti gli investimenti nella rete, nella fibra, nelle tecnologie, abbiamo ancora sperimentato 2 ore di inattività su tutte le nostre infrastrutture di Roubaix.

Una soluzione potrebbe essere quella di creare 2 sistemi di nodi ottici anziché uno. 2 sistemi significa 2 database e quindi se perdiamo la configurazione, solo un sistema è in discesa. Se il 50% dei collegamenti è passato attraverso uno dei sistemi, oggi avremmo perso il 50% della capacità ma non il 100% dei collegamenti. Questo è uno dei progetti che abbiamo iniziato 1 mese fa, i telai sono stati ordinati e arriveranno nei prossimi giorni. Possiamo avviare la configurazione e il lavoro di migrazione in due settimane. Data l’incidente di oggi, questo progetto è diventato una priorità per tutte le nostre infrastrutture, tutti i DC, tutti i POP.

Nell’attività dell’infrastruttura cloud, solo quelli che sono vigili fino al punto di paranoia dureranno. La qualità del servizio è fino a due elementi. Tutti gli incidenti che possono essere anticipati “dal design”. E gli incidenti dove impariamo dai nostri errori. Questo incidente ha costretto a sollevare il bardo ancora più alto per avvicinarsi al “rischio zero”.

Siamo sinceramente dispiaciuti per le 2 ore e 33 minuti di inattività sul sito RBX.


Cordiali saluti
Ottava

Share this
19 Set 2017

Newradio lancia lo streaming in HTTPS

Negli ultimi 2 anni sempre più siti internet si avvalgono di un certificato SSL per codificare in sicurezza i propri contenuti. In parole più semplici i siti certificati sono quelli che iniziano per https e che vengono visualizzati dai browser con un lucchetto verde alla sinistra della barra indirizzi. Oltre ad una maggior sicurezza sullo scambio dei dati con gli utenti, i siti in https vengono anche premiati dai motori di ricerca come Google perchè ritenuti più affidabili e sicuri. Anche molti siti di radio pian piano stanno migrando verso https e quindi sono aumentate anche le richieste di servizi di streaming in https per permettere di avere tutti i contenuti del sito certificati e sicuri.

Newradio ha introdotto ultimamente la possibilità di aggiungere il servizio https ai propri servizi di streaming sia Shoutcast2, Icecast e Wowza.
Per i servizi Wowza video e HLS audio, il link in https è da sempre disponibile di base. La grossa novità è per i normali servizi Shoutcast2 e Icecast che normalmente non vengono mai serviti con certificato. Il costo del servizio https su Shoutcast e Icecast dipende naturalmente dal numero degli slot del server. Un flusso di streaming certificato e molto più pesante da distribuire lato server perchè deve essere ‘codificato’ e questo necessita una notevole quantità di risorse aggiuntive.

Naturalmente il servizio di streaming certificato è perfettamente compatibile con il nostro player html5 PLAY5 che di base è già distribuito in formato https.

Il servizio di streaming in https su Shoutcast2 e Icecast è disponibile sia per le nuove attivazioni che su piani già esistenti.
Trovi tutte le informazioni necessarie ed i costi su questa pagina.

Se hai già un servizio di streaming con Newradio e vuoi aggiungere la funzione https contatta il nostro servizio clienti aprendo un ticket di supporto oppure chiamando lo 0683393633.

Share this
02 Lug 2017

MBStudio: DECRETO LEGISLATIVO 35/17

In conseguenza dell’ ADEMPIMENTO DEL  10 LUGLIO REPORT OPERE MUSICALI A SIAE E SOCIETA’ COLLECTING (DECRETO LEGISLATIVO 35/17) sto lavorando alla realizzazione di un generatore di report per gli utenti MB STUDIO PRO … una volta che il software di Report sara’ pronto bastera’ qualche click per generare il file di report da inviare. Dato che al momento sono disponibili solo linee guida ufficiose, il software subira’ modifiche in base alle decisioni che verrannno prese dalle parti.

Per il momento sara’ possibile generare un report contenente:
1) data e ora di messa in onda dell’opera
2) interprete – titolo dell’opera
3) durata trasmissione dell’opera
4) anno dell’opera (se disponibile in database)
5) produttore dell’opera (se disponibile in database)

Una funzionalita’ che verra’ aggiunta successivamente sara’ quella di ricercare anno e produttore dell’opera (ove assenti) su database liberi presenti su internet.

Il generatore di report è completamente gratuito per gli utenti MB STUDIO PRO e per scaricare la prima versione Beta cliccare sul seguente link:
http://www.mbradio.it/it/forum/3-mb-studio/77948-music-report-utility-di-rendicontazione#83289

 

Share this
29 Apr 2017

Aggiornamento MBStudio 8.59

MB STUDIO versione 8.59 è disponibile per Windows 10, 8, 7, Vista.

Potete scaricare gratuitamente l’aggiornamento dalla vostra area clienti.

novita’ rispetto alla versione 8.58:

  • Riproduce l’audio dei files video. I files video possono essere caricati e riprodotti ovunque in MB STUDIO e MB SPOT esattamente come i files audio. Successivi aggiornamenti permetteranno altresi’ la riproduzione dei files video per radiovisione.
  • E’ ora possibile gestire in maniera comoda i MidStreamTag. Vedere la guida
  • Supporto diretto dei codec RDS DEVA Broadcast. Vedere la guida
  • E’ ora possibile personalizzare in modo indipendente il formato dei testi per lo streaming, per il file OnAir.txt e per RDS. Vedere la guida
  • Canzoni: introdotto il nuovo parametro “Peso” regolabile da 0 a 10. Una canzone con peso 10 suonera’ 10 volte piu’ frequentemente di una canzone con peso 0 (non ha effetto su canzoni HitList). A partire da questa versione il “gradimento” di una canzone non influisce piu’ sulla sua frequenza di riproduzione.
  • Migliorati gli effetti Fade In / Fade Out
  • E’ ora possibile utilizzare i plugin VST (Selezionare VST Host DSP – dsp_vst.dll nel selettore DSP Plugin)
  • Meteo: è possibile scegliere tra gradi Celsius o Fahrenheit
  • Esportazione FTP: possibile abilitare/disabilitare FTP passive
  • Sulla playlist in onda, un click sulla linea proprieta’ non apre piu’ le proprieta’ ma equivale ad un click sullo slot. Vedere la guida.
  • In Edita Playlist è ora presente un filtro per visualizzare solo certi elementi della playlist
  • Rimossa la parola Demo, quando MB STUDIO viene eseguito su un computer privo di chiave cryptobox USB prende il nome di NoLicense. Cio’ permette di distinguere efficacemente la versione DEMO dalla versione client. Il file MBStudioDemo.exe puo’ essere cancellato dalla cartella MBStudio.
  • Altre piccole correzioni e miglioramenti
Share this
15 Dic 2016

Risolto problema di shoutcast1 su Chrome 55

A seguito di una modifica effettuata ai nostri server Shoutcast 1, attualmente il problema del non funzionamento dei server Shoutcast 1 su Chrome 55 e Safari su Sierra sembra superato. Le nostre radio in Shoutcast 1 sono tornate ascoltabili anche sugli aggregatori (tunein, Rdio, Zeptle etc etc).

Rimane il problema di Flash che potrebbe creare problemi su alcuni flussi in AAC+.  Se utilizzate Play5 ed i vostri browser e sistemi operativi sono abbastanza aggiornati, non dovreste avere particolari disservizi.

Share this
12 Dic 2016

CHROME 55: STOP a Flash e Shoutcast 1

Dall’introduzione del sistema operativo Sierra su Mac ed in particolare dal 6 dicembre 2016 con l’aggiornamento alla versione 55 di Google Chrome, sono state introdotte delle novità che si riperquotono sullo streaming audio:

  • E’ stato disabilitato FLASH di default
    Questo comporta che se i player non prevedono il supporto in HTML5 potrebbere non suonare più il flusso di streaming.  In particolare per i flussi in AAC+ che spesso vengono suonati da componenti FLASH dei player.
  • E’ bloccato l’utilizzo di Shoutcast 1.
    Questo perchè Shoutcast 1 utilizza una vecchia codifica in HTML1 che viene bloccata dai nuovi browser perchè ritenuto un protocollo pericoloso per la sicurezza.
    In pratica tutti coloro che hanno uno stream in Shoutcast 1 rischiano di non essere più ascoltati su Chrome 55 e Safari su Sierra. Questo vale sia per gli stream in Mp3 che AAC+
    Il problema vale anche per tutti gli aggregatori in rete come Tune-In, RDio, Zeptle etc etc. Sui loro players attualmente shoutcast1 non suona più su Chrome 55 e Safari.

Soluzioni:

Attualmente la nostra società ha trovato il modo di ‘aggirare’ il problema in alcuni modi:

Per chi ha uno stream in Shoutcast 2 o Icecast l’unico problema potrebbe essere l’utilizzo di AAC+. Stiamo verificando tutti i player PLAY5 in modo da ‘forzare’ l’utilizzo di HTML5 anche per AAC+.
Nessun problema dovrebbe esserci per gli stream in Mp3
Rimane il problema per le vecchie versioni dei sistemi operativi, in particolare Windows dalla versione Vista in giù (XP, 2000 etc etc). Il codec AAC+ è stato inserito in windows solo dalla versione 7 in poi, quindi nelle versioni precedenti non ci saranno modi di suonare un flusso in AAC+ se non abilitando il plug-in flash su Chrome manualmente. Consigliate sempre di aggiornare sistemi operativi e browser alle ultime versioni.

Per chi ha uno stream in Shoutcast 1 in Mp3 o AAC+, attualmente stiamo gradualmente inserendo un proxy sui player che permette di bypassare provvisoriamente il problema. A causa della grande mole di stream in Shoutcast 1 che abbiamo, i tempi potrebbero non essere immediati. Se avete delle particolari urgenze potete aprire un ticket sulla vostra area clienti per accellerare i tempi di aggiornamento del vostro player.
Se sul vostro sito non usate il nostro player PLAY5, vi consigliamo di farlo. Altri player potrebbero non funzionare più.
Naturalmente (in particolare con AAC+) il funzionamento del player è possibile solo con sistemi operativi e browser aggiornati alle ultime versioni.

La soluzione migliore è sicuramente quella di programmare un passaggio del vostro server da Shoutcast 1 a Shoutcast 2.  la cosa è possibile in modo gratuito ma comporta alcuni piccoli inconvenienti:

  • La perdita delle statistiche storiche del passato
  • Il cambio dei link diretti del flusso (quelli inviati agli aggregatori come Tune-in ad esempio), anche se quelli vecchi continueranno a funzionare regolarmente (ma sarà comunque bene aggiornarli al più presto)
  • La creazione manuale di un authash per la pubblicazione sulla directory di Shoutcast.com (con shoutcast 1 era automatica, con Shoutcast 2 esiste una procedura da effettuare. Nella guida di Shoutcast 2 è ben spiegato come fare).

Rimaniamo comunque a disposizione per qualsiasi chiarimento in merito a questa problematica.
Non esitate a chiamare il nostro supporto clienti per ulteriori informazioni.

Share this
06 Nov 2016

MB STUDIO 8.58.0

MB STUDIO versione 8.58 è disponibile per Windows 10, 8, 7, Vista

novita’ rispetto alla versione 8.57.4:

  • Piccole modifiche grafiche: gli slot sono piu’ corti e ne è visibile un numero maggiore, inoltre l’icona di preascolto si trova a sinistra come in tutte le altre finestre
  • E’ possibile selezionare piu’ slot in 2 click: click sinistro sull’icona di selezione slot per il primo, click destro sull’icona di selezione slot per l’ultimo
  • Velleman VM110: è ora possibile specificare l’indirizzo della scheda Velleman VM110 (è dunque possibile utilizzare piu’ schede collegate allo stesso computer, da usare con altri MB STUDIO o MB RECASTER)
  • Bug Fix: Memory leak grafico che in alcuni casi rendeva MB STUDIO lento o irresponsivo
  • Bug Fix: Esportazione verso FTP (venivano inviati files corrotti al server)
  • Altre piccole correzioni e miglioramenti

Potete scaricare l’aggiornamento direttamente dalla vostra area clienti Newradio nella sezione Downloads del vostro prodotto MB Soft.

Share this
19 Lug 2016

Aggiornamento MB Studio 8.57.3

Disponibile nella vostra area clienti MB STUDIO versione 8.57.3 per Windows 10, 8, 7, Vista

Cosa c’è di nuovo rispetto a 8.57.2:

  • La Configurazione\Cartelle ora include automaticamente anche le sottocartelle di primo livello senza necessita’ di aggiungerle alla lista. Vedere istruzioni qui.
  • A causa di un vecchio bug presente da versione 8.55.5 in poi, a mezzanotte non veniva effettuato il backup automatico dei piu’ importanti files di configurazione (.cfg)
  • A causa di un vecchio bug presente da versione 8.55.9 in poi, su alcuni computers raramente si verificano malfunzionamenti del webcast o blocchi dell’interfaccia grafica
  • Predisposto al funzionamento con MBLIVE per IOS di prossima uscita
Share this

© 2015 Newradio S.r.l. - P.Iva: 12075981006 - Rea: 1348600 Privacy Policy

Click Me