Jeg kører buddy i en win10 VM på en Qnap NAS
Jeg har også buddy på en w10-desktop
Al min medie ligger på NAS’en.
Jeg remuxer og re-encoder mkv til mp4.
Dette fungerer automatisk fint.
Men når jeg trækker (et vilkårligt antal) filer ind i buddy – sker der ingenting.
Jeg åbner derefter services.msc og klikker genstart MCEbuddy.
Buddy lukker så (forsvinder)
Jeg åbner derefter Buddy igen, og alle de tidligere trukne filer er der!! (og kører)
Dette sker både på VM- og desktop-versionerne.
Jeg går ud fra, at dette er den måde, det skal virke på i starten.
Rydder genstarten noget?
Måske tager GUI’en tid om at opdatere, mens motoren læser metadata for netværksfilerne. Hvis du venter længe nok, vil den til sidst opdatere, når motoren er færdig med at læse metadata. Prøv den nyeste 2.5.3 BETA-build – vi har forbedret GUI’ens responsivitet, når der arbejdes med manuelt tilføjede netværksfiler (drag n drop).
Det lyder som om, det blot tager tid at læse metadata. Genoptages det efter et par minutter, hvis det får lov at stå? (afhængigt af, hvor mange filer du trækker)
Jeg kører 2.5.3 BETA, og det tager også lang tid for MCEbuddy at påkalde de manuelt tilføjede filer. Er der nogen måde at manuelt påkalde det fra cli uden at genstarte tjenesten? Hvis jeg venter, sker det til sidst. Jeg antager, at den scanner biblioteket for nye medier og ikke påkalder den manuelle scanning, før biblioteksscanningen er fuldført.
Brug MCEBuddy.UserCLI.exe. Kør den blot uden parametre for at få hjælp:
Her er et eksempel på outputtet; du kan bruge --command=engine --action=rescan til at tvinge en genskanning:
Usage: MCEBuddy.UserCLI --command=<option> --action=<value> --server=<server> --port=<port> --quiet
--command=engine -> Change the engine state
--action=start -> Start engine
--action=stop -> Stop engine
--action=pause -> Pause engine
--action=resume -> Resume engine
--action=rescan -> Rescan monitor locations and logs
--command=query -> Query and prints various parameters about the engine and jobs
--action=queuelength -> Get number of jobs in the conversion queue
--action=enginestate -> State of the engine (stopped, started, conversion_in_progress or conversion_paused)
--action=withinschedule -> Prints 'false' if it is currently outside the configured conversion schedule otherwise 'true'
--command=jobstatus -> Query the status of a job in the queue
--action="<full file path>" -> The path and name of the source file for which the job status is being queried. Enclose the path and filename in quotes. Valid statuses are `queued`, `converting` or `not present`
--command=addfile -> Add file to the conversion queue
--action="<full file path>" -> Full path to file to add to conversion queue
--command=removejob -> Removes a job from the conversion queue
--action=<queue no> -> Enter the job number in the queue to remove from the conversion queue (first job is 1)
--command=priority -> Change MCEBuddy priority
--action=low -> Low priority
--action=normal -> Normal priority
--action=high -> High priority
--command=deletehistoryitem -> Remove a file entry from the history to enable reconversion
--action="<full file path>" -> Full path to processed file to remove from history
--command=upnp -> Set UPnP in gateway/router for MCEBuddy engine remote access
--action=enable -> Enable UPnP port forwarding for MCEBuddy
--action=disable -> Disable UPnP port forwarding for MCEBuddy
--command=firewall -> Configure firewall exception for MCEBuddy engine remote access
--action=enable -> Enable firewall exception for MCEBuddy
--action=disable -> Disable firewall exception for MCEBuddy
--server=<localhost/NetBIOS name/IP Address> -> (Optional) Address of MCEBuddy engine (default is localhost)
--port=<port no> -> (Optional) Port for MCEBuddy engine (default is 23332)
--quiet -> (Optional) By default verbose is on, if this parameter is set then it will only print the results of the command=query/jobstatus on screen and -2 if there is an error
The program returns 0 if successful, -1 for bad input parameters and -2 if failed to process the command
Examples:
MCEBuddy.UserCLI --command=addfile --action="C:\Videos\My Test.wtv"
MCEBuddy.UserCLI --command=query --action=queuelength
MCEBuddy.UserCLI --command=removejob --action=2
MCEBuddy.UserCLI --command=priority --action=low
MCEBuddy.UserCLI --command=deletehistoryitem --action="C:\Videos\My Test.wtv"
MCEBuddy.UserCLI --command=engine --action=pause
MCEBuddy.UserCLI --command=engine --action=pause --server=192.168.1.3
MCEBuddy.UserCLI --command=engine --action=pause --server=localhost --port=2234
MCEBuddy.UserCLI --command=query --action=enginestate --quiet
MCEBuddy.UserCLI --command=jobstatus --action="C:\Test\Recorded File.ts"
I stedet for at “trække og slippe” skal du prøve at bruge knappen “Tilføj”. Hvis det løser problemet, er det din Windows Explorer, der låser filerne; så når du trækker og slipper filen, kan MCEBuddy på det tidspunkt ikke få adgang til filerne. Den bedste måde at bekræfte det på er at åbne din mcebuddy.log-fil og kigge på logposterne efter du har trukket filerne ind i MCEBuddy. Hvis du ser beskeder om, at filerne er låst, er problemet med din Windows-konfiguration. Et simpelt tryk på knappen Genskan vil bekræfte det samme; når først filerne er låst op af din explorer (eller nogle udvidelser tilknyttet explorer), vil MCEBuddy kunne genbehandle dem.
Den langsigtede løsning er at finde ud af, hvilke udvidelser der er registreret i Windows Explorer, som blokerer adgangen til filer, når du markerer dem. Mange apps som VLC/codecs/afspillere eller andre urelaterede programmer registrerer udvidelser med Windows Explorer, som låser filer, når de markeres. Prøv en ren installation af Windows uden andre installerede apps, og du vil ikke se problemet.