Som mange af jer sikkert har opdaget så er der knas med DR NU Player addon’en. Der har længe været problemer med at afspille indhold, i hvert fald hvis man vil pause eller søge i videoen, og for nyligt tyder det på at API’et ikke opdaterer længere og derfor kommer nyt indhold ikke med i addon’en. Meget kunne tyde på det gamle DR NU API er lukket ned – dokumentationen er også blot blank nu.
Heldigvis er det ikke skidt det hele. DR har et andet API de i større grad bruger på dr.dk og jeg vil tro det overtager efter det gamle API. Jeg har lavet en såkaldt proof-of-concept opdatering til DR NU Player addon’en mod det nye API og det virker heldigvis! 🙂
Som bonus er der iOS m3u8 links tilgængelige så XBMC kan pause og søge i videoerne igen – endelig! fristes man til at tænke…
Testversionen af addon’en kan hentes her. Versionen er 3.9.0 og det er muligt at finde et program og se det. Alle de andre ting i addon’en er slået fra. Jeg arbejder videre med at få det slået til igen og finpudset. Lad mig høre om det virker for jer og hvilke OS, mv. i prøver på.
Det virker delvis her på en RPi — man kan se et program, men den hoster en del og hakker noget i billedet. Det er ikke fordi der mangler CPU kraft; CPU belastningen er på omkring 25-30% fra xbmc.bin (og ca 1% fra VCHIQ-0), men alligevel hakker billederne ca hver 2 sekund, med lidt ujævne mellemrum… det ser ud som om der mangler billeder.
Der kommer ikke noget løbende i log filen når den hakker (uddrag vedlagt nedenfor)
— Per.
20:55:56 T:3042443264 NOTICE: COMXPlayer: Opening: http://hls0.11003-od0.dna.qbrick.com/11003-od0/_definst_/mp4:CMS/Resources/dr.dk/NETTV/DR1/2013/08/7fb5a8e9-348d-4003-8937-478b560ab238/Skattejaegerne–10-12-_32f9a307e6964a4289b46bf7585de1ac.mp4/playlist.m3u8?ID=1561649
20:55:56 T:2237789248 NOTICE: COMXPlayer::OnExit()
20:55:56 T:2237789248 NOTICE: OMXPlayer: closing audio stream
20:55:56 T:2237789248 NOTICE: Closing audio stream
20:55:56 T:2942035008 NOTICE: thread end: OMXPlayerAudio::OnExit()
20:55:56 T:2431366208 WARNING: CRenderManager::FlipPage – timeout waiting for previous frame
20:55:56 T:2237789248 NOTICE: OMXClock using video as reference
20:55:56 T:2237789248 NOTICE: OMXPlayer: closing video stream
20:55:56 T:2237789248 NOTICE: Closing video stream
20:55:56 T:2431366208 NOTICE: thread end: video_thread
20:55:56 T:2237789248 NOTICE: OMXClock using video as reference
20:55:56 T:2237789248 NOTICE: COMXPlayer::OnExit() deleting demuxer
20:55:56 T:2237789248 NOTICE: COMXPlayer::OnExit() deleting input stream
20:55:57 T:2237789248 NOTICE: Thread COMXPlayer start, auto delete: false
20:55:57 T:2237789248 NOTICE: Creating InputStream
20:55:57 T:2237789248 NOTICE: Creating Demuxer
20:55:58 T:2237789248 NOTICE: Opening video stream: 1 source: 256
20:55:58 T:2237789248 NOTICE: OMXClock using video as reference
20:55:58 T:2237789248 NOTICE: Creating video thread
20:55:58 T:2431366208 NOTICE: Thread COMXPlayerVideo start, auto delete: false
20:55:58 T:2237789248 NOTICE: Opening audio stream: 2 source: 256
20:55:58 T:2237789248 NOTICE: Creating audio thread
20:55:58 T:2942035008 NOTICE: Thread COMXPlayerAudio start, auto delete: false
20:55:58 T:2431366208 NOTICE: Display resolution ADJUST : 1920×1080 @ 50.00 – Full Screen (22) (weight: 0.000)
20:55:58 T:3042443264 NOTICE: Using GL_TEXTURE_2D
20:55:58 T:3042443264 NOTICE: GL: Using BYPASS render method
20:55:58 T:3042443264 NOTICE: GL: NPOT texture support detected
20:55:58 T:2942035008 NOTICE: OMXClock using audio as reference
20:55:59 T:2431366208 WARNING: CRenderManager::FlipPage – timeout waiting for flip to complete
Hej Tommy,
Med OpenElec Frodo 12.2 (3.2.0) / Atom+Ion hænger plugin’et meget lang tid når man har valgt et bogstav. Efter 5 min. er der stadig ingen programliste, hvorefter jeg har lukket ned.
xbmc.log har ingen relevant info. Er der en særskilt log for drnu?
Mvh. Troels
Er det konsekvent? Ved hvilke bogstaver oplever du det?
Mvh.
Tommy
Fedt! Jeg tester det i aften (asrock m. windows 7)
Må jeg genbruge din kode til mit php script (til android tablets etc.)? Jeg skal nok indsætte en reference til dig.
mvh
Palle
Tommy,
Jeg har også oplevet noget som ligner det Troels beskriver, på min (xbian baserede RPi): Det sker ind i mellem at den hænger efter at have valgt et program, og så skal der vist et reboot til.
Omkring “hakkene” ovenfor, så virker det som om der sker noget mærkeligt med visse typer frames. En gang i mellem går det mere glidende når der f.eks. er en jævn panorering, men når der f.eks. er bevægelser i billedet så virker det som om der bliver byttet om på nogle buffere/frames — efter at have kikket lidt mere efter, så er det ikke bare frames der droppes men de bliver enten gentaget eller byttet om så de kommer i forkert rækkefølge.
Det har ikke været et problem med den tidligere DR.nu plugin.
Sig til hvis jeg skal teste noget særligt på min RPi!
Tak for dit arbejde med plug-in’et iøvrigt!
Så fik jeg testet på asrock ion 330 med windows 7 + xbmc 12.2
Interfacet kører upåklageligt (og dr.dk/mu er megahurtigt i forhold til det gamle api) – jeg kan fint browse a-z.
Afspilning er i ret dårlig kvalitet og virker ikke helt flydende – lidt som ombyttede frames som andre skriver.
Man kan spole uden problemer (herligt!).
Og kudos til dig: din kode er relativt let at læse!
MP4 linket virker upåklageligt (hakker ikke for mig i hvert fald):
RTSP: rtsp://om.gss.dr.dk/mediacache/_definst_/mp4:content/CMS/Resources/dr.dk/NETTV/DR1/2013/09/2f8992cb-6fe6-44ce-b11b-9eff6482c752/Bonderoeven–5-10-_a05168d8313940e8af8b211ab159ec92.mp4?ID=1587356”
MP4: http://vodfiles.dr.dk/CMS/Resources/dr.dk/NETTV/DR1/2013/09/2f8992cb-6fe6-44ce-b11b-9eff6482c752/Bonderoeven–5-10-_a05168d8313940e8af8b211ab159ec92.mp4?ID=1587356
Så en enkelt linie i python koden burde gøre det, tvapi.py, linie 70
uri = link[‘Uri’] –>
uri = link[‘Uri’].replace(“rtsp://om.gss.dr.dk/mediacache/_definst_/mp4:content/”, “http://vodfiles.dr.dk/”)
Det virker i hvert fald her på min test maskine (windows 7) – smider det lige op på xbmc og tester nu (jeg har sygt barn herhjemme så går lidt til og fra hyggeprojekter i dag)…
Det skal nok lige laves til ordentligt regulært udtryk, da dr sikkert ændrer server navne en gang imellem…
Hej Palle,
Min erfaring siger at filer på vodfiles ikke streamer godt i XBMC. Nogle gange får du enten kun lyd eller billed. Får du begge dele kan du ikke søge i videoen, dog godt pause og starte igen.
Derfor tror jeg der er mest fidus i at bruge de iOS links som DR stiller til rådighed. Jeg har dog ikke eksperimenteret med Android links endnu.
Mvh.
Tommy
Og lige testet på xbmc (windows 7, frodo 12.2) på asrock ion.
Og det spiller bare smukt når det kører på mp4 linket i stedet (så kunne man jo i teorien også lægge et download link ind i plugin).
Hej,
Ok – det virker nu smukt for mig på begge mine xbmc installationer – men de jo så også begge windows.
Og jeg kan altså sagtens pause og spole i tingene (med piletasterne) – så jeg synes da lige du skal prøve det – jeg er ikke streaming haj – men jeg kan bare se hvad der virker for mig.
Jeg har også eksperimenteret lidt videre her. Jeg har prøvet at hente rtmp streamen (vha rtmpdump 2.4 både fra Linux og fra OS X), og den fil, som modtages, er fejlbehæftet. Det virker næsten som om rtmpdump misser nogle keyframes og så går tilbage og beder om at få gensendt fra den forrige:
Første gang jeg hentede flv filen (OS X) fik jeg omkring 539 MB over. Anden gang (Linux) kom der 1.66 GB data(!) Når jeg henter den samme udsendelse i mp4 format vha wget fra vodfiles, så kommer der 237 MB.
Begge har jo nogenlunde samme H.264 stream inde i containeren, så vidt jeg lige kan se. De har ihvertfald alle nogenlunde samme bitrate når jeg spiller dem i VLC eller ffmpeg (1.000 – 1.500 k compressed), så den halve times udsendelse jeg har hentet burde kun være omkring 250 MB. Der kommer altså ekstra data ind i rtmp streams.
De to flv filer jeg har hentet vha rtmpdump kan jeg spille i VLC eller ffplay på Linux eller Mac, og også i xbmc på min RPi (xbian m/xbmc 12.2). MEN: De hopper også, omend med noget længere mellemrum end de filer som hentes direkte inde i xbmc på RPi’en — måske har det noget med bufferstørrelse at gøre i rtmp?
Både VLC og ffplay spytter fejl ud med løbende mellemrum “Missing reference picture”, hvorefter de hopper tilbage og spiller fra et tidligere tidspunkt. Typisk ser tidslinien i sekunder i ffplay sådan her ud for den ene fil:
0 … 23, 24!, 8, 9, …, 24!, 16, … 30!, 22, … etc
Det er nok det samme som sker inde i xbmc, blot med en meget mindre bufferstørrelse (måske nogle få hundrede ms imellem en gang imellem — det ser ihvertfald meget sådan ud).
Så mit gæt er at der er noget galt med rtmpdump og dr.dk interoperabilitiet på ihvertfald Linux, OS X og sikkert også Windows, som Palle har beskrevet ovenfor.
Virker det uden problemer hos dig, Tommy? Den fil jeg testede med her var Detektor fra i går aftes, i “høj” opløsning. Kan du hente den og spille den uden ryk på din xbmc? Hvilke versioner bruger du?
Hej Per,
Jeg har kun set nogle få usammenhængende klip pt, så jeg har ikke nok at danne grundlag med endnu. Jeg har dog ikke umiddelbart set den hakker, men jeg undersøger det.
Mht. dit problem med “kæmpe” filer downloadet med rtmpdump så skyldes det at rtmpdump forsøger at “speede” downloaden op så meget som muligt. Det gør den bl.a. ved at pause/genoptage streamen flere gange for at tvinge serveren til at sende data. En workaround til det er at bruge rtmpdump’s realtime parameter, så downloader den filen uden problemer. Det er samme problem vi oplever i XBMC, så konklusionen er at rtmpdump/librtmp ikke fungerer 100% med dr’s servere.
Det er derfor jeg hælder til at bruge iOS links. Jeg vil dog også prøve lidt mere med vodfiles streams, men jeg tror mange af de gamle videoer ikke virker her.
Mvh.
Tommy
Hej Tommy,
OK — så hvis jeg forstår dig rigtigt, så librtmp ikke så god at bruge med dr.dk… jeg troede egentlig at det var det, som blev brugt i drnu plugin’et, men jeg kan se det nok ikke er tilfældet:
Jeg har nemlig prøvet Palle’s “hack”, men det gjorde ingen forskel. Det er fordi linkene, her hos mig, ikke hedder rtsp men http — og så er der en “playlist” parameter som også skal fjernes. Lige nu se min tvapi.py nogenlunde sådan her ud fra linie 70 (meget LIDT elegant, jeg testede bare lidt ad gangen):
uri = link['Uri']
uri = uri.replace("rtsp://om.gss.dr.dk/mediacache/_definst_/mp4:content/","http://vodfiles.dr.dk/")
uri = uri.replace("http://om.gss.dr.dk/mediacache/_definst_/mp4:content/","http://vodfiles.dr.dk/")
uri = uri.replace("/playlist.m3u8?", "?")
Det ser ud til at virke, og nogle programmer som f.eks. “detektor” fra i går aftes, spoler fint. Andre, som f.eks. “bondemanden” spiller fint, men kan ikke spole overhovedet.
Men begge dele er trods alt bedre end kun at se meget hakkende video.
Er der en anden / nemmere måde at eksperimentere med hvilket link der hentes? Jeg kan ikke helt gennemskue (ud fra dr.dk’s api på http://www.dr.dk/nu/api/) hvordan man skelner mellem iOS, Android og/eller andre links?
Hej Tommy,
Problemet med at loade A-Z og programoversigter løste sig efter en genstart.
Dog har jeg ligesom de øvrige problemer med at videoen hakker/hopper over frames.
uri = link['Uri'].replace("rtsp://om.gss.dr.dk/mediacache/_definst_/mp4:content/", "http://vodfiles.dr.dk/")ser, også her, ud til at fungere bedre. Og fungerer fint når der spoles i videoen.Begge løsninger er dog 5-20 sek. om at fremvise et billede, fra man trykker på afspil i oversigten.
Hej Tommy.
Jeg har installeret version 3.9.0 – den ser ud til at have løst problemet med pause og spoling.
Desværre hakker videoen. I version 4.0.3 har jeg løst det ved at ændre fra iOS-format til Android-format, men det tillader version 3.9.0 ikke.
Håber snart du kan frigive en version over det nye API, der giver mulighed for at vælge format samt de mange andre muligheder der ligger i version 4.0.3. Det er en super add-on, så længe man ikke kommer til at trykke pause eller spole.
Jeg kører XBMC på Android (G-Box Midnight MX2).
Hej, både 3.9.0 og 4.0.3 er på det nye DR API, så jeg forstår ikke helt hvad du mener.
Har du set det jeg har skrevet tidligere om hakkende videoer i DR NU? http://tommy.winther.nu/wordpress/2013/04/11/problemer-med-hakkende-video-i-dr-nu/
Mvh.
Tommy
Hej Tommy.
Når jeg kører DR.NU via 4.0.3 og trykker pause eller spoler, så kan jeg ikke komme til at starte videoen igen. Den fryser når jeg igen trykker play og kommer aldrig op og køre igen. Slutresultatet er, at XBMC fryser og jeg må genstarte. Det oplever jeg ikke når jeg kører 3.9.0-versionen. I 3.9.0-versionen kan jeg fint sætte på pause og spole, tilgengæld må den have fat i f.eks. iOS-formatet der ikke kører godt på Gbox Midnight MX2. Videoer kører rigtigt fint på 4.0.3 når jeg vælger Android-format, tilgengæld har jeg her problemer ved pause/spoling…
Nogle forslag?
Har du prøvet vodfiles.dr.dk streamen? Den bruger jeg selv på min OUYA. Der virker pause/play typisk, men for det meste kan jeg ikke spole i streamen.
Mit bedste bud er at eksperimentere med alle fire typer af streams (iOS, Android, Streaming og vodfiles) og finde den som virker bedst for dig og dit hardware. Det er korrekt at 3.9.0 versionen brugte iOS streams.
Mvh.
Tommy