Die Rocket Beans API

Und das ist mein Problem. Ich hätte schon bock da drauf ne coole App zu bauen aber ohne die Möglichkeit auch B.O.C.K. zu haben wirds eher schwierig da Tage oder Wochen an Arbeit reinzustecken. :wink:

1 „Gefällt mir“

Ich werde das Thema morgen in einem Meeting ansprechen und hier dann baldmöglichst Feedback geben.

7 „Gefällt mir“

Super. Danke.

Wäre es eigentlich möglich, die youtube-Id, die es nun im ScheduleLegacy-Object gibt, auch beim NormalizedSchedule mitzugeben?

Gibt es die Typescript-Types als Package auf npmjs?

Ein Beitrag wurde in ein(e) bestehende(s) topic verschoben: Wunschliste

Derzeit nicht. Ich schließe nicht aus, dass das noch kommt, aber vorerst kann man ja mit denen aus dem Github-Repo arbeiten :slight_smile:

An dieser Stelle kurz vorm WE mal ein Danke und Chapeau an die Jungs für die OAuth-Implementation. Von vorne bis hinten reibungsloser Flow vom Erstellen einer App über die Verifizierung bis hin zur OAuth-Schnittstelle selbst. Funktionierte einfach alles out-of-the-box und ohne Probleme. :ok_hand:

Habe meine Rocket Beans Social Wall - #53 by Cyberblitzbirne damit problemlos mit einem rocketbeans.tv-Account-Login ausstatten können, und es läuft tadellos. Chapeau und Danke dafür, @DoomDesign @Yezirael @Kohbrax.

Einen kleinen Verbesserungsvorschlag hätte ich bei den Nutzungs- und Datenschutzbedingungen, die man für seine App eingibt: Wäre schön, wenn Zeilenumbrüche bzw. Absätze aus dem Textfeld auch im Modal des OAuth-Constent Screens übernommen würden. Derzeit ist der Text im Modal ganz ohne Umbrüche, was ihn IMO schwer zu lesen macht.

11 „Gefällt mir“

Vielen Dank. Freie Daten für frei Bohnen! :sunglasses:

Besonders geil finde ich ja die Zahl der aktuellen Stream-Views auf YT und Twitch. Ich hab beim Beansgraph mir was eigenes basteln dürfen. Wenn ich im nächsten Monat mal Zeit habe werde ich den Beansgraph auf die API portieren und damit reaktivieren. Und vielleicht auch noch etwas verbessern.

4 „Gefällt mir“

Auf der /v1/schedule/normalized Route bekommt man ja auch die duration (sec) und durationClass zurück. Jetzt frage ich mich, was es mit der durationClass auf sich hat. :sweat_smile:

Vielleicht hilft dir das hier weiter? :wink: So werden sie generiert:

public static getFrontendDurationClass(duration: number): number {
	if (duration > 13500) {
		return 4;
	} else if (duration > 9900) {
		return 3;
	} else if (duration > 6300) {
		return 2;
	} else if (duration > 2700) {
		return 1;
	} else {
		return 0;
	}
}

Ist nur fürs Websiten-Frontend, weil ich an die einzelnen Schedule-Items je nach Länge eine Klasse anhänge, welche die prozentuale Höhe bestimmt (damit längere Items optisch mehr Platz einnehmen).

3 „Gefällt mir“

Achso, danke für die schnelle Antwort. :grin:

Eine Game Two, oder RocketBeans App, für Android und die PS4 wären klasse :slight_smile: für Android mit Benachrichtigungs funktion :slight_smile: Und evtl SendungsAbo :grin: LG

1 „Gefällt mir“

bitte ignorieren, ich bin dümmer als ich dachte

Zur folgendem Websocket Event habe ich mal eine Frage:

AC_STREAM_INFO
Die laufende Sendung hat sich geändert
(beinhaltet außerdem die aktuelle Livestream URL, sowie die aktuelle Zuschauerzahl)

Das beinhaltet folgendes Objekt/Interface:

export interface streamInfoShow {
	title: string;
	topic: string;
	game: string;
	type: tMediaType;
	showId: number;
	timeStart: Date;
	timeEnd: Date;
	progress: number;
	viewers: streamCount;
};

Unter welchen Bedingungen gilt “Die laufende Sendung hat sich geändert”?

Zählt z.B. auch dazu, wenn die Sendung verlängert wird und sich damit timeEnd und progress ändern? Oder gibts das nur bei komplettem Sendungswechsel?

Ich habs noch nicht getestet und dachte, ich frage mal lieber direkt nach.

1 „Gefällt mir“

Ja, Änderungen an der laufenden Sendung zählen auch dazu.
Sieht man auf der Website manchmal, wenn der Fortschrittsbalken der Sendung verlängert wird (:donnie:), die Sendung selbst aber nicht wechselt.

4 „Gefällt mir“

Ich implementiere gerade ein paar Kleinigkeiten. Mir ist dabei aufgefallen, dass ihre keine Cache-Control-Header mitschickt. Jetzt muss ich mir Clientseitig eine Cachingstrategie überlegen.

Hintergrund: ich brauche relative häufig die Bohnen-Profile und würde es gerne vermeiden, euch damit tausendfach abzufackeln.

Es wäre schön, wenn ihr die Cache-Control-Header entsprechend setzen könntet (das sind für Bohnenprofile sicher andere als für den Sendeplan :stuck_out_tongue: ).

Grüße!

3 „Gefällt mir“

Könnt ihr noch auf die Fragen eingehen, die ich in diesem Thread oben gestellt hatte?

1 „Gefällt mir“

@baukran ich hole mir die Profile genau wie von dir beschrieben über bohne/portrait/all.
Ich habe mir jetzt mal eine TTL von 30 Minuten ausgedacht, die ist natürlich genau so gut wie 5 Minuten oder 24 Stunden :smiley:

@skceb
Guter Einwand :slight_smile: ich werde das mal entsprechend auf die Todo setzen, kann jedoch etwas dauern bis wir dazu kommen / es ausrollen

@baukran
Sorry hab vergessen zu antworten :(,
derzeit gibt es kein Ratelimit / steht auf der TODO :slight_smile: daher kann ich zu etwaigen Limits noch nicht viel sagen außer dass - wenn sie eingeführt werden sie vermutlich eher großzügig und nicht einschränkend ausfallen werden.
Generell ist es aber nicht falsch möglichst requestsparend zu arbeiten :slight_smile:

Die Endpunkte sind falsch in der Dokumentation (wird gleich gefixed)
Richtig wäre: https://api.rocketbeans.tv/v1/media/episode/byshow/304 sowie
https://api.rocketbeans.tv/v1/media/episode/byshow/unsorted/304
sowie jeweils die preview
https://api.rocketbeans.tv/v1/media/episode/byshow/preview/304 und
https://api.rocketbeans.tv/v1/media/episode/byshow/unsorted/preview/304

1 „Gefällt mir“