Drexel's VidUp - Ein templatebasierter Youtube Uploader

Du lädst mit 200Mbit hoch? Da bin ich etwas neidisch... xD

Zum ersten Thema mit dem neuen Startdatum: Hast Du auch auf den Button 'Recalculate Uploads with:' gedrückt? Dann gehts bei mir einwandfrei und so ist es auch gedacht.

Die anderen Probleme hören sich seltsam an und sind mir so noch nicht unter gekommen... Kann mir auch nicht vorstellen, dass VidUp zig GB RAM verbraucht, mehr als knapp über 1GB hab ich da nie gesehen... Hast Du das Tracing aktiviert in den Settings? Dann wäre es interessant mal die Trace Datei von so einem Fall zu sehen... Ich lade immer über Nacht hoch, deswegen sehe ich den Wechsel zwischen Videos selten, evtl. war das auch einfach ein Anzeigebug oder so... Habs gerade nochmal mit kleineren Dateien getestet, da war es kein Problem.

Auch 100GB und mehr sollten da keinen Unterschied machen.

Was ich in dem Log sehe:

Um 15:10 Uhr ersten Upload gestartet, der war um 15:27 fertig, dann wird noch Thumb und Playlist geaddet:

01.01.22 15:27:00.410: YoutubeVideoUploadService.Upload: Uploading finished.

01.01.22 15:27:00.410: YoutubeVideoUploadService.Upload: Reading answer.

01.01.22 15:27:00.410: YoutubeVideoUploadService.Upload: Reading answer finished.

01.01.22 15:27:00.412: YoutubeVideoUploadService.Upload: Upload finished with resume position 0, video id LzbAJYA01LI.

01.01.22 15:27:00.412: YoutubeVideoUploadService.Upload: End.

01.01.22 15:27:00.413: YoutubeThumbnailService.AddThumbnail: Start.

01.01.22 15:27:00.413: YoutubeThumbnailService.AddThumbnail: Video with thumbnail to add available.

01.01.22 15:27:00.622: HttpHelper.GetStreamContentUpload: Start.

01.01.22 15:27:00.622: HttpHelper.GetStreamContentUpload: End.

01.01.22 15:27:00.622: HttpHelper.GetAuthenticatedRequestMessageAsync: Start with uri.

01.01.22 15:27:00.622: HttpHelper.ensureAccessTokenAsync: Start, checking for access token.

01.01.22 15:27:00.622: HttpHelper.ensureAccessTokenAsync: End.

01.01.22 15:27:00.622: HttpHelper.GetAuthenticatedRequestMessageAsync: End with uri.

01.01.22 15:27:00.622: YoutubeThumbnailService.AddThumbnail: Add thumbnail.

01.01.22 15:27:04.143: YoutubeThumbnailService.AddThumbnail: End.

01.01.22 15:27:04.144: YoutubePlaylistItemService.AddToPlaylist: Start.

01.01.22 15:27:04.144: YoutubePlaylistItemService.AddToPlaylist: Videos to add available.

01.01.22 15:27:04.146: HttpHelper.GetStreamContent: Start.

01.01.22 15:27:04.146: HttpHelper.GetStreamContent: End.

01.01.22 15:27:04.146: HttpHelper.GetAuthenticatedRequestMessageAsync: Start with uri.

01.01.22 15:27:04.146: HttpHelper.ensureAccessTokenAsync: Start, checking for access token.

01.01.22 15:27:04.146: HttpHelper.ensureAccessTokenAsync: End.

01.01.22 15:27:04.146: HttpHelper.GetAuthenticatedRequestMessageAsync: End with uri.

01.01.22 15:27:04.146: YoutubePlaylistItemService.AddToPlaylist: Add to Playlist.

01.01.22 15:27:04.292: YoutubePlaylistItemService.AddToPlaylist: End.

Direkt danach um 15:27 wurde angefangen, die Datei #90# #Schatzsuche im Umland von Meglidunum 2#.mkv hochzuladen. Während des Uploads um 15:54 geht auf einmal was mit der Verschlüsselung des HTTP Transfers schief, was schon sehr seltsam ist (Das war auf dem Screenshot nicht zu erkennen, da stand ja nur An error occurred, liegt aber vermutlich auch nur daran, dass die Leitung weg ist...):

01.01.22 15:27:05.686: YoutubeVideoUploadService.Upload: Start uploading.

01.01.22 15:54:14.913: YoutubeVideoUploadService.Upload: HttpClient.SendAsync Exception resume position 0 try 1: System.Net.Http.HttpRequestException: An error occurred while sending the request.

---> System.IO.IOException: The decryption operation failed, see inner exception.

---> System.ComponentModel.Win32Exception (0x8009030F): Die zu überprüfende Nachricht bzw. Signatur wurde geändert.

Dann versucht er wie erwartet noch 3 Mal den Upload fortzusetzen, schlägt aber fehl, weil er gar keine Verbindung mehr bekommt, die Leitung scheint tot zu sein:

01.01.22 15:54:19.924: YoutubeVideoUploadService.Upload: Getting range due to upload retry.

01.01.22 15:54:19.931: YoutubeVideoUploadService.getResumePositionAsync: Start

01.01.22 15:54:19.931: YoutubeVideoUploadService.getResumePositionAsync: Requesting resume position, try 1.

01.01.22 15:54:19.931: HttpHelper.GetStreamContentContentRangeOnly: Start.

01.01.22 15:54:19.932: HttpHelper.GetStreamContentContentRangeOnly: End.

01.01.22 15:54:19.932: HttpHelper.GetAuthenticatedRequestMessageAsync: Start with uri.

01.01.22 15:54:19.932: HttpHelper.ensureAccessTokenAsync: Start, checking for access token.

01.01.22 15:54:19.932: HttpHelper.ensureAccessTokenAsync: End.

01.01.22 15:54:19.932: HttpHelper.GetAuthenticatedRequestMessageAsync: End with uri.

01.01.22 15:54:31.000: YoutubeVideoUploadService.getResumePositionAsync: Exception: System.Net.Http.HttpRequestException: Der angegebene Host ist unbekannt. (http://www.googleapis.com:443)

Also irgendwie scheint einfach die Internetverbindung weg zu sein.

Seh jetzt aber nicht, dass das an VidUp liegt, vor allem wenn Du es schon länger nutzt und es erst jetzt auffällt. Evtl stimmt auch gerade mit Deiner Internet Verbindung was nicht?

Ne, Du benötigst keine weitere Software außer Net5, aber ohne könntest Du es ja gar nicht starten. Über den Browser laden die sehr großen Dateien ohne Probleme hoch? Ich hatte mal ne Netzwerkkarte, die je nach Auslastungssituation auch gerne mal abgekackt ist...

Meine Dateien haben immer so 20GB und davon auch gerne mehrere hintereinander...

Im Prinzip schickt VidUp 32KByte Pakete über die Leitung, ich überlege ob das evtl. zu wenig sein könnte für so eine Uploadgeschwindigkeit und das irgendwann Stress macht. Kann Dir mal ein Version bauen die größere Pakete schickt, 512 KByte oder so, mal sehen ob das besser läuft. Aber je größer die Pakete, desto bescheidener für die Limitierung des Upload Speeds...

Klar, unten rechts bei Max Upload eine Zahl eintippen. in KByte/Sec, also bei Deinem Upload sollte so 30.000 das Maximum sein, alles darunter ist dann Drosselung.

Kann Dir morgen mal eine Version bauen.

Train92-YT erzählte mir die Tage auch schon sowas, dass Videos als Spam privat gestellt werden und er die dann nicht mehr veröffentlichen kann. Mich wundert das etwas, weil VidUp ja auch bis Dezmeber 21 nicht verifiziert war. Der einzige Unterschied war, dass VidUp publishing status öffentlich war, statt der eingeladene User Kreis, evtl könnt ihr das ja nochmal probieren:

Aber im Moment ist es ja eh egal, wo VidUp wieder genug Quota hat.

Edit: Hab auch mal die Anleitung angepasst.

So GameParadise hab Dir im Download Ordner noch einen Ordner Test angelegt, da liegt eine VidUp.Setup.1.12.1.Release.x64-512KBytePackage.exe drin, die sendet 512 KByte Pakete. Schau mal ob es damit besser ist. Es mach keinen Sinn, die Drossel niedriger als die halbe Paketgröße zu setzen, da mind. alle 2 Sek ein Paket gesendet wird, das müsste ich dann mal anpassen, sollte ich die Paketgröße mal variabel machen über die Settings.

Die Version hat sogar noch einen Bug in den Upload Statistiken gefixt, den die aktuelle Version noch hat.

Hm ok gut zu wissen, danke für die Rückmeldung. Behalte mal im Hinterkopf, falls noch jemand mit solchen Problemen ankommt.

War kurz dafür Dir ne neue Testversion zu bauen. xD Hatte noch die Funktion im Verdacht, die Die Daten von der Platte in den RAM liest. Es ist so, dass ich ca 100MB in dem RAM lade und die bis auf 40MB droppen/hochladen lasse, um dann wieder 60MB nachzuladen. Ich hatte das gemacht, weil ich nicht wollte, dass kontinuierlich ein paar KB von der platte geladen werden beim Upload, sondern größere Mengen im Block, wenn man mit der Upload Drossel nebenher zockt oder sonstwas macht, dass es nicht permanent I/O gibt. Außerdem schwankt der Upload über die API immer etwas, da wollte ich auch mal vermeiden, dass die I/O Zugriffe da was bremsen, aber in der Richtung hat nix was gebracht.

Wie auch immer, Um das Nachladen in die RAM Queue und das Abgreifen von der Queue für den Upload zu realisieren, habe die TPL-Datenflussbibliothek von Microsoft benutzt, das ist ein bißchen mit Kanonen auf Spatzen geschossen und seitdem schwankt der RAM Bedarf von VidUp auch zwischen 200MB und 1GB, ich hab auch keinen Einfluss darauf, wie lange diese Bibliothek was im RAM hält und wann sie was freigibt, deswegen hatte ich diese gerade im Verdacht, ich wollte die eh mal durch was einfacheres ersetzen, evtl. mach ich das die Tage mal. Aber dann ist es ja nicht mehr ganz so eilig, wenn Du den Übeltäter gefunden hast. Dann schmeiß ich die 512KB Version auch erstmal wieder weg.

Btw ich benutze seit langem kein Antivirus mehr, nur noch Microsoft Defender, die kommerziellen Lösungen sind eh größtenteils Schlangenöl, die sich wichtig machen, indem sie bei jedem Tracking Cookie Alarm schlagen z.B. Etwas übertrieben gesagt. Und dann machen sie auch noch solchen Stress. Wahrscheinlich hat das Antivirus das Lesen der Datei vollständig im RAM gehalten um sie irgendwann scannen zu können, wenn sie fertig ist. xD Wobei ich mich frage, warum das nicht im RAM Usage des Antivirus angezeigt wird. Du hast recht, es gibt so gesharte Memory Pages, die nicht direkt einem Programm zugeordnet werden, in der Regel sind die aber eigentlich zu vernachlässigen...

Zitat von fellpower

GZ zu der neuen Quota. Nur frage ich mich, wie lange das halten wird. Soweit ich weiß nutzen ja nun echt viele, auch viele "Großen", dein Tool. Neulich wurde das sogar im Stream von Gronkh gepostet. Denke, daher kommen auch die vielen neuen Nutzer. China spielt wohl auch ganz groß mit.

Wäre - seitens Google - noch mehr Quota drin irgendwann - oder müssen wir das Tool irgendwann aufgeben, weil es einfach zu viele nutzen?

Bei Gronkh erwähnt? Nice xD Hast Du zufällig den Link zu dem Stream?

Man kann bei Google jederzeit mehr Quota beantragen, gestern schrammte es knapp unter 4 Mio Verbrauch vorbei, mal sehen wie lang 6 Mio reichen...

Da die App jetzt einmal verifiziert wurde und zum zweiten mal mehr Quota genehmigt wurde, bin ich guter Dinge, dass das zukünftig auch machbar sein wird. Wenn nicht muss wie gesagt jeder seinen eigenen API Zugang verwenden. Ich bin da auf jeden Fall von den jeweiligen Entscheidungen Googles abhängig, sollten große Steamer/Uploader das Tool verwenden, könnten diese natürlich im Falle einer Absage auch mal mehr öffentlichen Druck ausüben. Oder Google macht selbst mal son Tool und stellt mich als Produktmanager ein. xD

Gerade gesehen: Das mit den eigenen API Credentials ist für die Tonne:

Zitat von YouTube

All videos uploaded via the videos.insert endpoint from unverified API projects created after 28 July 2020 will be restricted to private viewing mode. To lift this restriction, each API project must undergo an audit to verify compliance with the Terms of Service. Please see the API Revision History for more details.

https://developers.google.com/youtube/v3/docs/videos/insert

https://developers.google.com/…#release_notes_07_28_2020

https://www.vidup.info/2022-01…te-about-future-releases/

Eigentlich hatte ich es erst nur hier geschrieben, aber dann doch auch auf der Homepage veröffentlicht. Aber da ich den Text eh auch auf deutsch habe:

Kleines Update:

1. Gestern war VidUp bei über 5.000.000 Quota Usage, das ist fast schon wieder am Limit, ich habe schon wieder mehr Quota beantragt.

2. Mir ist in den API Statistiken zum ersten Mal aufgefallen, dass auch API Requests genutzt werden, die ich für VidUp gar nicht nutze:

Es sind nicht viele in 2 Wochen, Video Uploads sind 35.000 dagegen, dennoch scheint jemand meinen API Zugang zu nutzen. Das kann ich auch nicht verhindern, da die Zugangsaten aus einer Desktop APP halt raus zu bekommen sind. Dennoch werde ich dazu über gehen, mit jedem Release, die Zugangsdaten zu erneuern, quasi ein neues Passwort vergeben. Das hat zur Folge, dass die alten Versionen sofort nicht mehr nutzbar sind und die neue Version genutzt werden muss. Schade für die Leute die gerne länger bei einer alten Version bleiben, aber so ist es halt, wenige Penner verderben der Mehrheit immer den Spaß. Und nein es wird keine Auto Updater für die App geben, zumindest nicht von mir.

3. Ich habe die VidUp Entwicklungsumgebung gestern auf Visual Studio 2022 geupdatet, bisher war es 2019 und auch das benötigte .NET Framework auf .NET6 angehoben. Wäre zwar nicht zwingend nötig gewesen, aber .NET6 soll auch an einigen Stellen performancetechnisch zugelegt haben, das kann ja nicht schaden. Also mit der nächsten Version wird .NET6 benötigt.