版本 2.5.3 和 2.5.4 会显示音轨错误，并开始缓慢重封装。版本 2.5.2 没有此错误，我已回退到 2.5.2。查看日志文件发现 fprobe 报错，同时生成的文件体积约为原文件的 3 倍，转换速度也变慢。
我已附上 2.5.4 与 2.5.2 的日志文件：
ver 2_5_2 News 5 20090411 [20200807-2200].mpg-News %-2020-08-08T09-03-32.0686042-04-00.log (681.4 KB)
ver 2_5_4 News 5 20090411 [20200807-2200].mpg-News %-2020-08-07T18-34-15.log (851.2 KB)
問題似乎是您的檔案正在被另一個程序鎖定，導致 mcebuddy 無法存取，從而引發您的問題。
WARNING → 嘗試讀取資料到 TS 檔時發生錯誤。錯誤：System.IO.IOException: 程序無法存取檔案 ‘C:\Users\Public\Recorded TV\HDHomeRun\News 5\News 5 20090411 [20200807-2200].mpg’，因為它正被另一個程序使用。
2020-08-07T18:34:15 MCEBuddy.AppWrapper.Base → C:\Users\Public\Recorded TV\HDHomeRun\News 5\News 5 20090411 [20200807-2200].mpg: 權限被拒
此外，當您執行 2.5.4 時，是以 headless 模式（無使用者登入）執行，而 2.5.2 則是在有使用者登入的情況下執行：
2020-08-07T18:34:19 MCEBuddy.AppWrapper.Comskip → 以 UISession 程序啟動，具有管理員權限。這需要系統中至少有一位使用者登入（遠端桌面或本機）
WARNING> 2020-08-07T18:34:19 MCEBuddy.AppWrapper.Comskip → 無法從 NonUI Session 建立具有管理員權限的 UI Session 程序。是否有使用者登入？
感謝您的回覆。我對於使用者自動登入這點相當困惑，因為我已設定為重開機後自動登入。我在同一個 Windows 工作階段中同時安裝了 5.2 與 5.4，結果兩者在我的 Windows 筆電上都出現相同情況。測試用的檔案是事先錄好的，並非即時錄製，因此不應該有其他程序佔用。
我目前執行的是最新的 Windows 更新，因為我別無選擇。奇怪的是 5.2 完全不受這些問題影響，而 5.4 卻會。您有什麼建議可以讓我檢查嗎？我希望能使用最新版本。這是個很棒的產品，我自從剪線後就一直使用它。
祝好
Larry
goose，
我正在运行 mcebuddy 的捐赠者版本。
我再次尝试并查看了日志文件，结果类似。我发现 ffprobe 被拒绝访问该文件。
2020-08-19T13:45:10 MCEBuddy.AppWrapper.Base → \MY-MEDIA\Public\Recorded TV\HDHomeRun\The 100\The 100 S07E11 20200812 [20200813-0000].mpg: Permission denied.
这显然会锁定文件，从而导致以下错误：
→ 尝试读取 TS 文件数据时出错。错误：System.IO.IOException: 进程无法访问文件 ‘\MY-MEDIA\Public\Recorded TV\HDHomeRun\The 100\The 100 S07E11 20200812 [20200813-0000].mpg’，因为该文件正被另一进程使用。
我曾尝试通过在其程序目录下运行 ffprobe 并使用你的命令行参数来重现该错误，但它运行正常并输出了预期结果。因此我认为这不是 ffprobe 的权限问题。
我注意到 5.2 版本在使用 guest 用户名登录时不会失败，而 5.4 版本在使用 guest 用户名时会失败。
手动添加用户名 → Guest
手动添加密码 →
存档路径域名 →
存档路径用户名 → Guest
存档路径密码 →
失败路径域名 →
失败路径用户名 → Guest
失败路径密码 →
如有任何帮助，感激不尽。
谢谢
Larry
The 100 S07E11 20200812 [20200813-0000].mpg-DVR-Comm-2020-08-19T13-45-09.log (72.1 KB)
The 100 S07E11 20200812 [20200813-0000].mpg-DVR-Comm-2020-08-19T14-09-47.9638908-04-00.log (108 KB)
不是MCEBuddy内部的任何程序锁定了文件，而是外部因素。可能是你的网络机器上的某个东西，或者是杀毒软件。试着使用本地文件，如果那样可以，你就知道是网络驱动器上有什么东西在干扰。
我這邊沒有這個設備所以無法測試，但有看到回報說，如果你使用 HDHomeRun DVR 服務（因為你的資料夾名稱是 HDHomeRun），有時候錄影結束後檔案的鎖定不會被解除。如果你有設定 MCEBuddy 在錄影結束後馬上轉檔，也許需要把時間拉長一點？
我之前用 MediaPortal（使用 HDHomeRun 調諧器）時，也遇過檔案鎖定沒被釋放的問題，現在改用 Emby 就沒再發生過。我會在錄影結束後大約 5 分鐘才開始轉檔。
Goose，
所有錄製的節目都存放在同一台電腦上，Hdhomerun、mcebuddy、Kodi 都在同一台電腦裡。
我把《The 100》這部影集移到 Downloads 資料夾，並手動加入 mcebuddy，結果還是一樣：
C:\Users\ldc76\Downloads\The 100 S07E11 20200812 [20200813-0000].mpg: Permission denied
5.2 版不會出現這個問題，但 5.3 和 5.4 會。所以這幾個版本之間一定有某種差異，導致在這台電腦上出問題。奇怪的是，其中一台 Dell 筆電可以正常運作，另一台同型號卻不行，錯誤訊息相同。我已經檢查過所有權限，看起來都沒問題；手動跑 fprobe 在同一檔案上也不會報錯。但只要 mcebuddy 5.4 或 5.3 去啟動它，就會出現這個錯誤。
所以我真的卡住了，不知道下一步該怎麼辦。我不想被困在 5.3 版。
Larry
David，
感谢回复。我正在通过手动把节目添加到 MCEBuddy 来测试这个问题。目前的情况是：当 5.3 或 5.4 启动 ffprobe 时会报错，而 5.2 不会。奇怪的是，两台完全相同的戴尔笔记本里，一台正常，另一台却不行。MCEBuddy、HDHomeRun、Kodi 都跑在同一台桌面服务器上。我之所以发现这个问题，是因为一旦 ffprobe 报错，程序就会进入“慢速 remux”，耗时极长，它误以为音频有故障。
我已经从 mcebuddy\ffmpeg 目录手动执行了同样的 ffprobe 命令、同样的参数、同样的节目文件路径，都能正常输出，因此权限应该没问题。但只要由 5.3 或 5.4 调用，就会失败。
2020-08-19T20:22:23 MCEBuddy.AppWrapper.Base --> Launching process C:\Program Files\MCEBuddy2x\ffmpeg\ffprobe.exe
2020-08-19T20:22:23 MCEBuddy.AppWrapper.Base --> Process arguments -hide_banner -probesize 100M -analyzeduration 300M -i "C:\Users\ldc76\Downloads\The 100 S07E11 20200812 [20200813-0000].mpg"
2020-08-19T20:22:23 MCEBuddy.AppWrapper.Base --> UI Session Admin Process : False
2020-08-19T20:22:23 MCEBuddy.AppWrapper.Base --> Setting process priority to Idle
2020-08-19T20:22:23 MCEBuddy.AppWrapper.Base --> Setting CPU affinity to -> 15
**2020-08-19T20:22:23 MCEBuddy.AppWrapper.Base --> C:\Users\ldc76\Downloads\The 100 S07E11 20200812 [20200813-0000].mpg: Permission denied**
**--> Process exited with code 1**
> 2020-08-19T20:22:25 MCEBuddy.Engine.ConversionJob --> Running custom commands
2020-08-19T20:22:25 MCEBuddy.Transcode.CustomCommand --> Engine running as service, enabling PreMetaCustomCommandUISession, since PreMetaCustomCommandShowWindow is enabled
2020-08-19T20:22:25 MCEBuddy.Transcode.CustomCommand --> Custom command parameters read ->
PreMetaCustomCommandPath =
PreMetaCustomCommandParameters =
PreMetaCustomCommandHangPeriod = 300
PreMetaCustomCommandCritical = False
PreMetaCustomCommandUISession = True
PreMetaCustomCommandShowWindow = True
PreMetaCustomCommandExitCodeCheck = False
> 2020-08-19T20:22:25 MCEBuddy.Transcode.CustomCommand --> No custom commands found
2020-08-19T20:22:25 MCEBuddy.Engine.ConversionJob --> Finished pre metadata custom command, source file size [KB] 3,423,865.00
> 2020-08-19T20:22:25 MCEBuddy.Engine.ConversionJob --> Getting show information and banner from Internet sources
2020-08-19T20:22:25 MCEBuddy.MetaData.VideoMetaData --> Extracting metadata from file -> C:\Users\ldc76\Downloads\The 100 S07E11 20200812 [20200813-0000].mpg
--> Checking for SiliconDust meta tags
--> Starting to extract payload from TS file, upto 64 TS packets will be processed
**WARNING> --> Error trying to read data to TS file. Error: System.IO.IOException: The process cannot access the file 'C:\Users\ldc76\Downloads\The 100 S07E11 20200812 [20200813-0000].mpg' because it is being used by another process.**
如有任何排查思路，感激不尽！
谢谢
Larry
一时没来得及细查……是不是 Windows 搜索或其他索引程序在索引这些文件路径？很容易把文件锁住。
謝謝。我會試著關閉它。也許如果我知道 5.2 到 5.3 之間做了哪些改進，我就能找到線索。如果今天有機會，我會比較我的兩台筆電，看看能否發現什麼。
此致
Larry
你可以在這裡找到版本資訊：Announcements - MCEBuddy
我沒有看到任何與 ffmpeg 或這個相關的變更。從這些日誌中我看不出來，請檢查你的監控位置專家設定中是否有設定延遲，以防止鎖定的檔案在加入佇列前被傳送到 mcebuddy。
Goose
我检查了更改，也认为没有什么明显的问题会导致这个错误。今天偶然间，我用两个不同的播出日期运行了同一个节目：三月份的那个没有报错，而八月份的那个在5.4版本上会报错。两者在5.2版本上都能通过。
我把这两个文件以及每个版本的日志文件上传到了你的FTP站点，位置在ldc7675-test目录下。
如果你有空，也许可以运行一下，看看是否也遇到同样的错误。顺便感谢你调查这个问题，确实很诡异。
我在两台完全相同的D830笔记本上进行了测试，结果报错和通过的情况完全一致。还没在台式机上试过。
Larry
您上傳的檔案在 2.5.4 版這裡都能正常轉換
2020-08-21T08:46:26 MCEBuddy.AppWrapper.Base → Launching process C:\Program Files\MCEBuddy2x\ffmpeg\ffprobe.exe
2020-08-21T08:46:26 MCEBuddy.AppWrapper.Base → Process arguments -hide_banner -probesize 100M -analyzeduration 300M -i “C:\Users\Goose\Desktop\News 5 20090411 [20200810-2200].mpg”
2020-08-21T08:46:26 MCEBuddy.AppWrapper.Base → UI Session Admin Process : False
2020-08-21T08:46:27 MCEBuddy.AppWrapper.Base → Setting process priority to Normal
2020-08-21T08:46:28 MCEBuddy.AppWrapper.Base → [mpeg2video @ 00000207993c2940] Invalid frame dimensions 0x0.
2020-08-21T08:46:28 MCEBuddy.AppWrapper.Base → Last message repeated 7 times
2020-08-21T08:46:28 MCEBuddy.AppWrapper.Base → [mpegts @ 000002079939b140] PES packet size mismatch
2020-08-21T08:46:28 MCEBuddy.AppWrapper.Base → Input #0, mpegts, from ‘C:\Users\Goose\Desktop\News 5 20090411 [20200810-2200].mpg’:
2020-08-21T08:46:28 MCEBuddy.AppWrapper.Base → Duration: 00:30:59.67, start: 27431.266511, bitrate: 9147 kb/s
2020-08-21T08:46:28 MCEBuddy.AppWrapper.Base → Program 3
2020-08-21T08:46:28 MCEBuddy.AppWrapper.Base → Stream #0:0[0x31]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 1920x1080 [SAR 1:1 DAR 16:9], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
2020-08-21T08:46:28 MCEBuddy.AppWrapper.Base → Stream #0:10x34: Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 384 kb/s
2020-08-21T08:46:28 MCEBuddy.AppWrapper.Base → Stream #0:20x35: Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, stereo, fltp, 128 kb/s
→ Process exited with code 0
重新封裝也沒問題
2020-08-21T08:47:15 MCEBuddy.AppWrapper.FFmpeg → video:1899108kB audio:116218kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 3.189370%
→ Process exited with code 0
→ FFMpeg output file size [KB] → 2,079,602.00
2020-08-21T08:47:17 MCEBuddy.RemuxMediaCenter.RemuxMCERecording → Original file size [KB] → 2,076,550.00
2020-08-21T08:47:17 MCEBuddy.RemuxMediaCenter.RemuxMCERecording → Remuxed file size [KB] → 2,079,602.00
我認為可能是您的安裝或 Windows 設定有問題。
鹅
谢谢，现在我知道我的三台电脑都出问题了。可能是Windows的问题。
此致
拉里
Goose
我想我找到問題了。我在所有電腦上都使用同一個 mcebuddy.conf 檔案。看起來這個檔案裡有某些東西是 (5.4) 版本對我的任何任務都不喜歡的。我可以複製一個任務並執行該任務，而且不會出現任何錯誤。
我在附加的設定檔中使用了 news% 任務並複製了 news5 任務。
試試看，看看你是否也遇到相同的問題。
所以，如果有必要，我可以透過複製我所有的任務來解決這個問題。
謝謝
Larry
mcebuddy.conf (16.3 KB)
请不要手动编辑 mcebuddy.conf 文件。所有操作都可以通过图形界面完成，包括升级 MCEBuddy 时。MCEBuddy 在升级以及通过图形界面保存设置时都会进行完整性检查。
我们在多个地方都放置了此警告，包括 ReadMe 文件以及讨论论坛的 高级设置 文档页面：
请不要用旧配置文件替换新配置文件，因为每个版本都会添加/更新新参数。
注意：自 v2.3.13 起，MCEBuddy.conf 中的所有可配置参数（除 FFmpegBackupRemux 外）均可通过图形界面访问，路径为 设置 → 专家设置 页面。您无需手动编辑 mcebuddy.conf 文件。
您可以使用 MCEBuddy 图形界面复制任务，右键点击任务并选择 Duplicate
Goose。
我明白你的意思。我向你保证，我从未手动编辑过配置文件。我一直都让程序在升级时自行处理配置文件，从不干预。在 5.2 到 5.4 的多次安装测试中，我都得到了相同的结果。因此，无论出于什么原因，我的电脑上的新配置结构似乎都没有被更新。
笔记本上保存的是大约 6 到 8 个月前我从台式机配置任务中复制过来的旧版本。
既然现在我知道该如何修正，我会像往常一样在图形界面里重新创建任务，然后删除旧的。花不了多少时间。
感谢你测试我的文件，结果让我找到了解决办法。
希望其他人不会遇到这个问题。
此致
敬礼
Larry
请注意，每台电脑都需要单独购买安装许可证。详情请见我们的网站。
Goose
我只使用桌面伺服器來跑 mcebuddy。筆電只是用來協助驗證問題，反正它們的速度太慢，不適合做轉檔。
最後只能從頭重建，用全新的設定檔。舊的設定檔裡有某些東西在 5.4 版會出問題，但神奇的是 5.2 版卻沒事。
此致
Larry