Probleme mit BITS

[jaenicke]

Ich habe dies heute Morgen kurz ausprobiert. Bei mir ist der Aufruf erfolgreich. Kann es sein, dass du an deinem System etwas verändert hast? Gewisse Tuning-Tools deaktivieren diesen Dienst zum Beispiel gerne, obwohl es ja nicht so ist, dass er nicht benötigt wird.
Probiere es am besten einmal auf einem frischen System oder in einer neu aufgesetzten VM.

Zitat von Medium:

Du weist dem Pointer die Adresse 0 zu. (BG_JOB_TYPE_DOWNLOAD ist das erste Element im Enum BG_JOB_TYPE, und hat somit automatisch den numerischen Wert 0.)

Welcher Pointer? Der zweite Parameter ist vom Typ BG_JOB_TYPE, also genau der Enumeration, von deren Typ auch pJobType ist. Das p für Pointer ist in dem Variablennamen allerdings ungünstig gewählt.

Zitat von Medium:

Aber ich wage zu bezweifeln, dass dies das Problem löst. Soweit sich meine kurze Googelei darstellte, scheint dieser Weg (diese Komponente bzw. das Framework) auch nicht sonderlich populär. Was stört dich an den ganz normalen Socket Komponenten, oder den Indys? Gerade mit den Indys sollte das ein Kinderspiel sein, und man findet massig Doku und anderes Material dazu im Netz.

BITS bietet schon eine Menge mehr Möglichkeiten als man selbst einfach mal so umsetzen kann. Das System lädt die Datei zum Beispiel komplett im Hintergrund mit niedriger Priorität herunter und benachrichtigt dich, wenn sie da ist.

Jemand hier im Forum hat darüber auch glaube ich schon auf den Delphi-Tagen gesprochen, mir fällt nur der Name nicht ein...

[himitsu]

Zitat von jaenicke:

Jemand hier im Forum hat darüber auch glaube ich schon auf den Delphi-Tagen gesprochen, mir fällt nur der Name nicht ein...

Ich glaub das letzte oder vorletzte Jahr? (von diesma weiß ich nichts)

Zitat von jaenicke:

BITS bietet schon eine Menge mehr Möglichkeiten als man selbst einfach mal so umsetzen kann. Das System lädt die Datei zum Beispiel komplett im Hintergrund mit niedriger Priorität herunter und benachrichtigt dich, wenn sie da ist.

Im Grunde ist es ja vorallem genau dafür gedacht.
* Nur "Einer" muß ins Internet (nur BITS, wegen der Firewall),
* der kann alles in Ruhe runterladen, wenn der Rechner Zeit hat, bzw. wenn ein passendes Netzwerk zur Verfügung steht (z.B. nicht über's teure Handynetz)
* und nicht jedes poplige Programm muß einen eigenen Updateservice installieren, der ständig läuft, oder selber bei jedem Programmstart nachgucken.

Wir hätten uns die Raumpläne aufheben sollen, um nochma nachgucken zu können.

[HolgerX]

Hallo..

Habe auch mal vor einiger Zeit etwas mit BITS rumgespielt..

Allerdings habe ich die ganze Job-Geschichte in einen eigenen Thread ausgelagert, welcher auch den Status abfrägt und entsprechend Rückmeldung gibt.

Von dort habe ich mal etwas heraus gezogen:

Delphi-Quellcode:

procedure InitJob(AFileNameSource : WideString; AFileNameTarget : WideString);
var
  Bits : IBackgroundCopyManager;
  Job: IBackgroundCopyJob;
  JobID: GUID;
begin
  CoInitialize(nil);
  try
    try
      Bits := CoBackgroundCopyManager_.Create;

      // Erstellen neuen Job
      Assert(Succeeded(Bits.CreateJob('BITSJob', BG_JOB_TYPE_DOWNLOAD, jobID, job )));

      // Fileeinträge erzeugen
      Assert(Succeeded(job.AddFile(PWideChar(AFileNameSource), PWideChar(AFileNameTarget))));

      // Priorität setzen
      Assert(Succeeded(job.SetPriority( BG_JOB_PRIORITY_HIGH )));

//    ... Status-Abfragen

      job := nil;
    except
      on E: Exception do
        ShowMessage('Exception : ' + E.Classname + ': ' + E.Message);
    end;
  finally
    CoUninitialize;
  end;
end;

Dies verwendet die angehängte TLB, jedoch weiß ich nicht mehr, wo die her ist.
Auch ist die TLP für die BITS Vers. 1 und noch nicht für die Vers. 2, funktioniert auf Windows 7 aber problemlos.

Mit BITS können übrigens nicht nur Dateien aus dem Internet herunter geladen werden, sondern auch aus dem Lokalen Netz.

[GreatCornholio]

Danke für die Antworten!

Also teilweise kann ich Entwarnung geben.
Habe es gerade noch mal mit frisch gestartetem PC probiert, und mit fest gesetztem JobType-Parameter wird der Job nun fehlerlos erstellt, und es kann sogar eine Datei heruntergeladen werden.
Anscheinend hat sich "nur" der BITS-Service aufgehängt, aber so seltsam dass er zumindest noch teilweise funktioniert hat...

Was allerdings immer noch nicht geht, ist die Übergabe des JobTypes als Variable, dort kommt immer noch die gleiche Fehlermeldung wie vorher.
Ich kann Sachen machen wie:hRes:= m_Manager.CreateJob('Test', BG_JOB_TYPE(0), rJobID, pJob); , das funktioniert.
Aber das hier funktioniert nicht:

Delphi-Quellcode:

var
  i: Integer;
  ...
begin
  ...
  i:= 0;
  hRes:= m_Manager.CreateJob('Test', BG_JOB_TYPE(i), rJobID, pJob);

Warum ich BITS verwenden will wurde ja schon angesprochen.
Ich will große Dateien aus dem Internet laden, ohne mich darum kümmern zu müssen, und wenn sie irgendwann fertig sind bekomme ich eine Nachricht.

[HolgerX]

Hmm..

Bei meiner TLB ist der Typ für BG_JOB_TYPE als

TOleEnum = type LongWord;

definiert.

Bei deiner Version ist es direkt der Aufzählungstyp!

Vielleicht gibt es hier ja Unterschiede?

Aber wenn Du eh nur Downloads und keine Uploads machen willst, dann ist es doch egal und Du kannst auch direkt 0 als Konstante einsetzen.

[himitsu]

Zitat:

LongWord

Delphi-Quellcode:

{$MINIMUMENUMSIZE 4}
BG_JOB_TYPE = .....;
{$MINIMUMENUMSIZE 1}

In Delphi sind ENUMs nur so groß, wie nötig. (also oft nur 1 Byte)
In C++ sind sie fast immer "UNSIGNED INT" (4 Byte)

[GreatCornholio]

Ha!
Danke für den Tip, das wars!

MfG

[GreatCornholio]

So, jetzt ist leider das nächste Problem aufgetaucht.
Hat schon mal jemand erfolgreich einen Programmaufruf bei Beendigung des Downloads implementiert?
Also über die Funktion IBackgroundCopyJob2.SetNotifyCmdLine()?

Ich kann mir erfolgreich einen Zeiger auf das IBackgroundCopyJob2-Interface holen, SetNotifyCmdLine aufrufen, und bekomme immer OK zurück.
Aber wenn ich einen Download starte, das Programm beende und warte, passiert einfach nichts, das Kommando wird nicht ausgeführt.
Mit bitsadmin.exe /list kann ich den Fortschritt und die Fertigstellung des Downloads verfolgen.
Ich kann sogar mit bitsadmin /info {GUID} /verbose mein Kommando sehen:

Code:

GUID: {GUID} DISPLAY: 'Test'
TYPE: DOWNLOAD STATE: TRANSFERRED OWNER: ich
PRIORITY: HIGH FILES: 1 / 1 BYTES: 70517025 / 70517025
CREATION TIME: 23.09.2016 15:55:21 MODIFICATION TIME: 23.09.2016 15:57:00
COMPLETION TIME: 23.09.2016 15:57:00 ACL FLAGS:
NOTIFY INTERFACE: UNREGISTERED NOTIFICATION FLAGS: 27
RETRY DELAY: 600 NO PROGRESS TIMEOUT: 1209600 ERROR COUNT: 0
PROXY USAGE: PRECONFIG PROXY LIST: NULL PROXY BYPASS LIST: NULL
DESCRIPTION:
JOB FILES:
        70517025 / 70517025 WORKING http://www.domain.de/MeinTestFile.zip -> D:\BITS Test\MeinTestFile.zip
NOTIFICATION COMMAND LINE: '"C:\Windows\System32\notepad.exe"'
owner MIC integrity level: MEDIUM
owner elevated ?           false

Peercaching flags
         Enable download from peers      :false
         Enable serving to peers         :false

CUSTOM HEADERS: NULL

Als CommandLine habe ich den Namen meines Programms (mit ParamStr(0)) und notepad.exe, jeweils mit und ohne Anführungszeichen verwendet.
Ich habe schon verschiedene Prioritäten verwendet, BG_JOB_PRIORITY_FOREGROUND und BG_JOB_PRIORITY_HIGH.
Die NotifyFlags vor und nach der CommandLine gesetzt.
Aber nichts funktioniert, obwohl es eigentlich funktionieren müsste...

[jaenicke]

Ich hoffe dir ist klar, dass du ein von dort gestartetes Programm nicht in der Oberfläche sehen wirst. Denn das läuft im Systemkontext und nicht im Benutzerkontext.

Bist du sicher, dass das Programm nicht gestartet wird? Hast du einmal im Taskmanager geschaut? Oder ein Programm gestartet, das einfach nur eine Datei testweise in einem festgelegten Ordner ablegt?