ARTE: keine aktuellen Filme mehr

[pidoubleyou]

Wie im Forumgemeldet, gibt es ab dem 1.7. keine neuen ARTE-Filme mehr.
Die API für die Ermittlung der Filme, die an einem Tag gelaufen sind, gibt es nicht mehr.

[pidoubleyou]

Zwischenstand:
Grundsätzlich werden mit der Lösung im Branch für diesen Issue wieder die Filme gefunden.
Allerdings werden Datum und Zeit teilweise nicht bzw. nicht korrekt gefüllt.

Ich habe im Code in einem Kommentar mit TODO einen Lösungsweg beschrieben, falls jemand vor mir Zeit hat, sich darum zu kümmern.

[alex1702]

Ich guck es mir mal an.

[alex1702]

So klappt soweit ist aber noch nicht hübsch gemacht.

[pidoubleyou]

Ich hab den Fix gerade noch etwas getestet. Zwei Punkte sind mir aufgefallen:

• Es gibt ein paar Exception mit Zugriffen auf JsonNull beim Auslesen von Kategorien. Scheint aber nur zwei Livestreams zu betreffen, die nur kurzfristig angeboten werden.
• die neue Struktur beinhaltet teilweise mehrere Ausstrahlungstermine: aktuell wird der erste in der Json-Struktur genommen. Das ist nicht unbedingt der aktuelle, so dass die Sendungen mal unter einer Zeit in der Vergangenheit oder in der Zukunft erscheinen.

@alex1702 @Nicklas2751 Ich schlage vor, dass wir das erst fixen, bevor wir den Hotfix auf die Crawler bringen, um unnötige Forumsdiskussionen zu vermeiden.

[alex1702]

ähm ja könnte knapp sein bevor der neue verwendet wird. hatte nicht auf Plausibilität geprüft nur ob Daten bis auf livestream da sind.

[alex1702]

ok crawler sind erstmal wieder bei der vorherigen version.

[alex1702]

hast du schon eine idee wie wir rausfinden welches Ausstrahlungsdatum das richtige ist?

[pidoubleyou]

Ich hab es im Branch aktuell hinbekommen, dass das Erstausstrahlungsdatum verwendet wird. Führt bei Wiederholung dazu, dass Einträge, die z.B. gestern gelaufen sind, für das Jahr 2015 gelistet werden.

Die ARTE-Struktur beinhaltet folgende Infos:
Beispiel 1:

• FIRST_BROADCAST: 03.11.2015
• MAJOR_REBROADCAST: 05.07.2017
• MINOR_REBROADCAST: 03.11.2015, 13.11.2015, 06.07.2017

Beispiel 2:

• FIRST_BROADCAST: 06.07.2015
• MAJOR_REBROADCAST: 28.08.2017
• MINOR_REBROADCAST: 10.07.2017

Ich habe leider keine gute Idee, wie ich erkennen kann, dass in Beispiel 1 MAJOR_REBROADCAST statt FIRST_BROADCAST der richtige Eintrag ist, in Beispiel 2 aber FIRST_BROADCAST korrekt ist.

Einzig vielleicht eine Logik wie: wenn MAJOR_REBROADCAST <= "heute", dann MAJOR_REBROADCAST, sonst FIRST_BROADCAST.

Habt ihr andere Ideen? Sollten wir diese Logik einbauen?

[zxsd]

Bei den Beispielen kriege ich ein 401 Fehler ... entweder oAuth oder Geo. Wenn diese als vollkommene .txt-Dateien vorhanden wären, würde ich sie gerne mal anschauen.

[alex1702]

@zxsd Man braucht den Token zum authentifizieren.

Also ich bin mir im moment unsicher welches Datum man eigentlich nehmen sollte. Theoretisch plädiere ich garnicht mehr dazu das Datum der Erstausstrahlung zu nehmen, weil wenn ich grad ein Film oder so z.B. im TV verpasst habe oder nachträglich den gucken will oder halt zukünftig den gucken möchte, dann suche ich ja nach dem aktuellen Datum und nicht 2 Jahre zurück. Außer ich suche halt über Titel/Thema/Sender.
Also ich weiß nicht ob wir nicht irgendwann mal das System so umbauen sollten dass ein Film unter mehren Daten auffindbar ist.
Anderes Thema ist natürlich auch Abos, sollte nicht mehr nur Erstausstrahlung vorkommen, dann schlagen die natürlich jedes mal an wenn eine Wiederholung kommt. Eventuell solte man da auch später eine kollisionsabfrage machen ob es eine Wiederholung ist oder doch nicht.
Ich würde dann auch alle Ausstrahlungsdaten mit zu dem Film packen und nur in MV dass dann in mehrere Filme spalten oder halt irgendeine andere Lösung dafür finden.
Soviel zu meinen Zukunftsvisionen.

Zum aktuellen Zeitpunkt weiß ich nicht was jetzt besser wäre letzte mögliche Ausstrahlung oder erste.
Also suche des kleinsten Datums oder des größten. (Glaub irgendwo hatten wir schonmal die diskussion hier ^^)
Nach deiner Logik da oben wäre es bei Beispiel 1 das zweit neuste Datum und bei Beispiel 2 der älteste.

So wie ich das aktuell anhand der Beispiele gesehen habe scheint arte auch von oben nach unten aktueller zu werden. Warum die son schwachsinn wie major und minor rebroadcast machen erschließt sich mir aber noch nicht.

[alex1702]

@zxsd
Beispiel 1 : https://p.elaon.de/y2lxpSSaAgBM7qJvvYqc/json
Beispiel 2 : https://p.elaon.de/M7870Z3J/json

[alex1702]

Und was machen wir bei solchen Sendungen:
http://www.arte.tv/de/videos/076465-000-A/syrien-die-schlacht-um-raqqa
Laut zweiten API-Link hat es garkeine Publishing infos.
Eventuell könnte man da das Datum seit dem es online verfügbar ist nehmen (VRA oder ähnliches)
Gibt 5 Filme/Sendungen mit leerem Datum.

[zxsd]

@alex1702 ... Danke aber funzen tat es nicht (FF-nativ und DownThemAll, wie abgebildet).

[zxsd]

ein Film unter mehren Daten auffindbar

... könnte Verwirrung stiften.

Wenn die anderen Daten zusätzlich im (vergrößerten) Beschreibungsfeld hineingeschrieben worden wären -- beispielsweise mit Verkettungszeichen als Abgrenzung (wie in den Statusleisten), und Sternchen (für den aktiven Wert) -- könnte eventuell ein wißbegieriger User daraus Sinn machen. Derartige MServer-Änderungen müßten aber mit MediathekView-Änderungen erfolgen ... und es ginge zwei Zeilen 'verloren.' (Daten sind aus obigem Beispiel 1.)

Wie ich 'mal beim ZDF postulierte, wenn ein Depublizierungsdatum vorhanden wäre, könnte man mittels diesem wohl das derzeit 'richtige' Publizierungsdatum feststellen.

[alex1702]

@zxsd Warum hast du an die Links was dran gehängt? die kannst du so im browser öffnen mit drauf klicken.

[zxsd]

^^^^^ . . . . Bin eben Angsthase <g>.

Mutmaßungen ... (hauptsächlich Beispiel 1 berücksichtigt)

Wenn die Sendung keine Erstausstrahlung ist, wird es wohl wie Beispiel 1 veröffentlicht; sonst wie Beispiel 2.

BROADCAST und REBROADCAST Daten sind primär für Ausstrahlungszwecken bestimmt. Meist überlappen sich Gebrauch und lizenzrechtliche Gesichtspunkte hinsichtlich Fernsehen und Mediathek, da die Mediathek erst später das automatisierte Ausstrahlungsverfahren ergänzte.

FIRST_BROADCAST und MAJOR_REBROADCAST im obigen Posting lehnen sich an die begrenzten Zeitspannen an, indem die jeweilige Sendung mittels der Arte-Mediathek zu beziehen ist/war; die Mediathek-relevante Zeitspanne beginnt mit der jeweiligen Ausstrahlung. MINOR_REBROADCAST ist eine ausgestrahlte Wiederholung, welche mit der Mediathek kaum was zu tun hat.

videoRights und catchupRights scheinen die Mediathek-Zeitspannen mehr relevant zu sein. Meiner Meinung nach haben nur aktuelle Sendungen, videoRights. (Gegenwärtig gleichen videoRights und catchupRights, wobei nur aktuelle Sendungen videoRights 'besitzen.') Nach dem Depublizieren einer Sendung kann man die Zeitspanne vergangener Veröffentlichung(en) von den übrig gebliebenen catchupRights ablesen.

Im ersten Beispiel scheint videoRightsBegin ausschlaggebend zu sein. Wenn sich dieses Muster mit anderen Sendungen wiederholen täte ?.?.? Ich schlage vor das Datum zu bestimmen, wenn folgenden Werten im Einklang sind:

arteSchedulingDay
catchupRightsBegin
videoRightsBegin

Anmerkung: Das Datum im videoRightsEnd-Wert gleicht Depublizierungsdatum wenn meine Mutmaßungen stimmen.

Mittels eine IE-only Seite habe ich folgende interessante Werten bezüglich Beispiel 1 gefunden:

FIRST_BROADCAST: 03.11.2015
---------------------------
"broadcastBeginRounded":"2015-11-03T07:30:00Z",
"arteSchedulingDay":"2015-11-03",                <--  <--  <--  <--
"broadcastType":"FIRST_BROADCAST",
"broadcastBegin":"2015-11-03T07:32:07Z",
"broadcastEnd":"2015-11-03T07:58:01Z",
"catchupRightsBegin":"2015-11-03T07:32:07Z",        <--  <--  <--  <--
"catchupRightsEnd":"2016-02-01T07:32:07Z"

MAJOR_REBROADCAST: 05.07.2017
-----------------------------
"broadcastBeginRounded":"2017-07-05T14:50:00Z",
"arteSchedulingDay":"2017-07-05",            <--  <--  <--  <--
"broadcastType":"MAJOR_REBROADCAST",   
"broadcastBegin":"2017-07-05T14:48:28Z",
"broadcastEnd":"2017-07-05T15:14:22Z",
"catchupRightsBegin":"2017-07-05T03:00:00Z",        <--  <--  <--  <--
"videoRightsBegin":"2017-07-05T03:00:00Z",        <--  <--  <--  <--
"videoRightsEnd":"2017-10-03T03:00:00Z",
"catchupRightsEnd":"2017-10-03T03:00:00Z"

[pidoubleyou]

@zxsd Danke für die Analysen. Ich werde heute Abend mal ausprobieren, was passiert, wenn ich die catchupRights berücksichtige.

[pidoubleyou]

Die Logik funktioniert in den meisten Fällen korrekt. Leider gibt es noch ein paar Filme, bei denen die Ausstrahlung vor dem Onlinezeitraum liegt, z.B. http://www.arte.tv/de/videos/071363-007-A/paare

Das muss ich mir nochmal anschauen.

[zxsd]

z.B. http://www.arte.tv/de/videos/071363-007-A/paare

Offensichtlich bin ich nicht schlau genug ... Kann mir jemand sagen was ich falsch tue?

[zxsduser@CentOS7 ~]$ wget --debug --header="Authorization: Bearer Nzc1Yjc1ZjJkYjk1NWFhN2I2MWEwMmRlMzAzNjI5NmU3NWU3ODg4ODJjOWMxNTMxYzEzZGRjYjg2ZGE4MmIwOA" --header="host: developers.arte.tv" "https://api.arte.tv/api/opa/v3/programs/de/071363-007-A"
Setting --header (header) to Authorization: Bearer Nzc1Yjc1ZjJkYjk1NWFhN2I2MWEwMmRlMzAzNjI5NmU3NWU3ODg4ODJjOWMxNTMxYzEzZGRjYjg2ZGE4MmIwOA
Setting --header (header) to host: developers.arte.tv
DEBUG output created by Wget 1.14 on linux-gnu.

URI encoding = ‘UTF-8’
Converted file name '071363-007-A' (UTF-8) -> '071363-007-A' (UTF-8)
Converted file name '071363-007-A' (UTF-8) -> '071363-007-A' (UTF-8)
--2017-07-10 08:20:50--  https://api.arte.tv/api/opa/v3/programs/de/071363-007-A
Resolving api.arte.tv (api.arte.tv)... 212.95.74.30
Caching api.arte.tv => 212.95.74.30
Connecting to api.arte.tv (api.arte.tv)|212.95.74.30|:443... connected.
Created socket 3.
Releasing 0x000000000129dea0 (new refcount 1).
Initiating SSL handshake.
Handshake successful; connected socket 3 to SSL handle 0x00000000012b2d50
certificate:
  subject: /C=FR/L=Strasbourg/O=ARTE/CN=*.arte.tv
  issuer:  /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2
X509 certificate successfully verified and matches host api.arte.tv

---request begin---
GET /api/opa/v3/programs/de/071363-007-A HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Accept: */*
host: developers.arte.tv
Connection: Keep-Alive
Authorization: Bearer Nzc1Yjc1ZjJkYjk1NWFhN2I2MWEwMmRlMzAzNjI5NmU3NWU3ODg4ODJjOWMxNTMxYzEzZGRjYjg2ZGE4MmIwOA

---request end---
HTTP request sent, awaiting response... 
---response begin---
HTTP/1.1 404 Not Found
Server: openresty
Date: Mon, 10 Jul 2017 07:20:46 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: PHPSESSID=0123456789abcde; expires=Mon, 10-Jul-2017 08:00:00 GMT; Max-Age=3600; path=/; HttpOnly
Cache-Control: private, must-revalidate
pragma: no-cache
expires: -1

---response end---
404 Not Found

[alex1702]

@zxsd wie wäre es mit einfach link anklicken? es ist eine ARTE Mediathek seite und keine api url.

[Herand]

ich wollte allen, die sich um eine Arte-Lösung kümmern und einsetzen mal in diesem Rahmen hier ganz herzlich danken, ich habe technisch keine Ahnung und kann nur anbieten zu helfen, wenn es hilft!?
Arte bring wunderbare Sendungen und Ihr alle macht sehr viele sehr Glücklich, wenn man schon bald wieder Arte in der MediathekView finden kann! Denn manchmal schafft man es einfach nicht, innerhalb der 7 Tage alles zu schauen, was Arte bietet.... Die spannende O.J. Simpson-Doku ging sogar 450 Minuten! Danke!!

[zxsd]

@alex1702 ... Ich wollte halt die API-Angaben anschauen.

---

Mir wurde erst vom @Nicklas2751 beigebracht, daß Seiten-Quelltexte nicht API-Angaben widerspiegeln. (Und ob! <g>) Laut Seite-Quelltext (Zeile 288) ist diese Sendung:
Online vom 26. Juni
Aber ein API-passendes Datum ist darin nicht zu finden ... geschweige denn 201706 oder 062017, bzw., 2606 oder 0626 (mit und ohne Punkt/Bindestrich).

Nicht 'mal die Player-Config-Seite enthält das Datum im API-geliefertem Format ... aber was ähnliches ist vorhanden:
"VRA": "26/06/2017 15:20:00 +0000",
Ich vermute das schon von Dir erwähnte VRA so viel wie "Video Rights Anfang" bedeutet ... also gleicht videoRightsBegin im API.

---

Ohne Crawler, versuche ich die API-Angaben selbst zu holen. Mir gelingt es nicht, deswegen meine Frage.

[alex1702]

@zxsd So geht es:
curl -H "Authorization: Bearer Nzc1Yjc1ZjJkYjk1NWFhN2I2MWEwMmRlMzAzNjI5NmU3NWU3ODg4ODJjOWMxNTMxYzEzZGRjYjg2ZGE4MmIwOA" htps://api.arte.tv/api/opa/v3/programs/de/071363-007-A

Benutze aber selber Insomnia für die Requests.

[zxsd]

^^^^^ Danke!

---

Vollständigkeitshalber (und vom curl-Kommando dankend übernommen), geht's auch mit wget.

Durch folgende Meldung habe ich mir gedacht, host definiert werden mußte. (Problemen, die mit CygWin-wget aufgetaucht waren, führten auf Abwege ...)

X-Http-Git-Revision: 5490515
X-Cache-Status: EXPIRED
Access-Control-Allow-Origin: https://developers.arte.tv . . . . 🔴 .
Access-Control-Allow-Methods: GET, HEAD, POST, OPTIONS
Access-Control-Allow-Headers: Accept, Authorization

---

[zxsduser@CentOS7 ~]$ wget --header="Authorization: Bearer Nzc1Yjc1ZjJkYjk1NWFhN2I2MWEwMmRlMzAzNjI5NmU3NWU3ODg4ODJjOWMxNTMxYzEzZGRjYjg2ZGE4MmIwOA" "https://api.arte.tv/api/opa/v3/programs/de/071363-007-A"
--2017-07-10 11:50:46--  https://api.arte.tv/api/opa/v3/programs/de/071363-007-A
Resolving api.arte.tv (api.arte.tv)... 212.95.74.30
Connecting to api.arte.tv (api.arte.tv)|212.95.74.30|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]
Saving to: ‘071363-007-A’

    [ <=>                                                                                       ] 20,615      --.-K/s   in 0.007s  

2017-07-10 11:50:47 (2.78 MB/s) - ‘071363-007-A’ saved [20615]

[zxsduser@CentOS7 ~]$

[Nicklas2751]

Ich würde vorschlagen, man erfasst FIRST_BROADCAST, MAJOR_REBROADCAST und MINOR_REBROADCAST und nimmt von den Daten das, was am nächsten an heute dran ist also den geringsten Abstand hat.

Bei Beispiel 1 hätte
FIRST_BROADCAST (03.11.2015) zu heute (11.07.2017): 616 Tage
MAJOR_REBROADCAST (05.07.2017) zu heute: 6 Tage
MINOR_REBROADCAST (03.11.2015, 13.11.2015, 06.07.2017) zu heute: 616, 606, 5 Tage

also würde ich hier den 06.07.2017 als Datum nehmen.
Wenn eine Sendung in unserer Filmliste bereits vorhanden ist wird diese ja nicht ersetzt und damit bleibt die Sendung mit dem alten Datum vorhanden.
Technisch können wir pro Datum den Abstand zu heute in Tagen errechnen und dann mit <int: tage,date: datum> in eine SortedMap speichern und dann für dann den Eintrag für firstKey() (kleinster Key) als Datum setzen.

Und beim neuen Film Objekt im MLib dvelop würde ich entsprechend auch noch das Datum wieder aus dem equals und hashcode raus nehmen und das ganze auf Duration, Titel, Thema, Sender, Urls, GeoLocs und Subtitles eingrenzen.

[Nicklas2751]

Wie ich gesehen habe entsprich dies ja auch dem Verhalten wie @pidoubleyou mit fec7236 eingebaut hat. Der aktuelle branch stand sollte damit m.M passen. @alex1702 Hast du den mal geteset?

[pidoubleyou]

Jetzt sieht es gut aus. Für alle Einträge wird ein sinnvolles Ausstrahlungsdatum gesetzt.
Meine Stichproben waren alle plausibel und stimmten mit der ARTE-Seite überein.

[alex1702]

also steht einem release nix im weg?

[pidoubleyou]

Pull Request habe ich erstellt, kannst du mergen und releasen.

[Nicklas2751]

Wurde auch zu Develop gemerged. Änderung: Nutzung von LocalDateTime statt dem veralteten Calendar. + LocalDateTime statt Strings da die neue Film klasse ja ein LocalDateTime statt einem String erwartet.

[Elbrecht]

Hi all –

arte.tv is back again – never change a winning team!

HE