フォーラムへの返信
-
投稿者投稿
-
ありがとうございます。
今回のケースでは、該当したアルバム（ファイル）が他のアプリケーションにエンキューされていた状態ではなかったと思います。まず最初にTBのプロパティ編集で０にした（他のアプリではそのアルバムは触っていなかった状態）もののツリービュー上が更新されなかったので、他のソフト（MusicBee)でみたところ、COMPILATIONが０になっていたため、ファイル上は書き換わっていると思い、TBにてUpdate Databaseを実行した流れだったように記憶しています。
とはいえ、
「今回のケースでは、手動クロールや自動クロールでは、タイムスタンプが更新されないので読み取り損ねた”0″はいつまでも更新されませんが、データの更新を行うと、あらためてファイルを読み取ることでデータベースとの差異に気が付きますので、データベースの内容が”1″に是正されると思います。」
とおっしゃっている動きについては、そのように振る舞っていたように思いました。
以上です。
ありがとうございました
ありがとうございました
DB Updateしないと反映されないことがある件についてですが、まさかですがディスプレイドライバとの相性原因とかあるでしょうかね・・・
いま手元のパソコンで出た現象ではないので正確にわからないのですが、現象がでたパソコンではTB起動時に「Intelのグラフィックドライバのバージョンが古いから新しくせよ」的なメッセージが出ます。
ようは、見た目だけが更新されてないのか、ということ
関係ないでしょうね。、、
わかりました
ありがとうございました
Version 65.0.3325.146 (Official Build) (32-bit)に更新すれば大丈夫でした。
Naos 様
ご教示いただきありがとうございました
>エンコーダのパスは、基本設定のエンコードツールのところ
すみません、見つけられません💦
「基本の設定」の、そのまた何処にありますでしょうか。
よろしくお願いします。
Attachments:
ありがとうございました
なるほど
では、複数あるときは、どのようなルールで選ばれるのですかMP4動画とキャプチャ画像を置き、TBがManage Images…でFolder Imagesで表示している場所：デスクトップ
↑
今次懸念対象のMP4動画を楽曲と呼ぶのであれば、左様です。
デスクトップ上の、DHCに云々というのがMP4動画、*.pngがキャプチャ画像などです。
Attachments:
厳密に申すとこういう環境です。
楽曲（管理フォルダ）：G:ドライブ（外部HD）の\Files\Flac と\Files\MP3
MP4動画とキャプチャ画像を置き、TBがManage Images…でFolder Imagesで表示している場所：デスクトップ
考えようによっては、デスクトップがこのMP4動画およびその他PNGファイルの管理フォルダとみなされているのかもしれませんが。。。
よろしくお願いします。
TBは、Library Viewerにファイルをドロップしたら、自動的に管理フォルダのどこかになにかを保存するみたいな機能があったりしますのですか？
ありませんねぇ。
人生には『三つの坂』がある。上り坂・下り坂・まさかの坂(まっさかさま)人生思い掛けぬ落とし穴がある。何が起きるか、『まさかの坂』でございます。
銅像。
05.png スクロール前（上部）
06.png スクロール後（下部）
よろしくおねがいします
Attachments:
朝イチでTBを立ち上げたところ、昨日終了したときの状態で、Library ViewerにMP4ファイルの画像（誤っているもの）が表示されていました。
その画像で右クリックしてManage images…をみると、Cache Imageとして誤りの画像（フォーラムに投稿した画面キャプチャPNG画像）が登録されていました（01.png)。
どうやら、なんらかのタイミング・原因で、MP4ファイルのアイコン情報が別の画像ファイルのものとしてTBに認識されてしまったようです（OSが管理している情報でしょうか？）。
それで、このプロパティ画面上で、このキャッシュ画像を右クリックDeleteし、あらためてMP4ファイルをLibrary Viewerにドロップしたところ、今度はそれを示す画像が本日作成した別のキャプチャ画像（上記したChace Imageが示されているプロパティ画面の画像）になりました。どうやら、そのときにデスクトップに置かれているPNG画像、あるいは直前にWindowsのPhotosユーティリティで表示した画像などをTBがLibrary Viewer表示用の画像として取り扱っているように見えます。その画像はTBの画像管理プロパティ上では、Chahe Imageとして取り扱われています。
昨日も、フォーラムの別トピックで画像添付すべく、まず画面キャプチャした画像をデスクトップに置いて、それをWindowsのPhotosでちら見し、Chromeを使ってフォーラムに添付送信、その後MP4ファイルをTBのLibrary Viewerにドロップ、という作業経緯だったように思います。
素人ユーザには不可思議千万な動きですが、開発者の方なら原因が推察できるかもと期待。
参考まで、わたしが行ったと記憶している手順を記述します。
OSはWinwows10 (x64) 最新状態（Fall Creators Update、最新パッチレベル）
１．Youtubeの動画をMP4としてデスクトップにDL
２．TBを起動し、Library ViewerにこのMP4ファイルをドロップ。このときは、MP4動画の画像（アイコン）が表示されたと思う（うろおぼえ）。その後、いったんLibrary ViewerからDELでこの画像を削除。
３．TBの画面をPrtScrnでキャプチャし画像編集ソフトで少しいじってデスクトップにPNG保存
４．その画像をWindowsのPhotosで表示
５．ChromeでTBのフォーラムに投稿、そのときこの画像を添付送信
６．TBのLibrary Viewerに再度MP4ファイルをドロップ。すると画像がフォーラムで投稿したPNG画像に。以降は、この画像をLibrary ViewerからDELしてあらためてMP4をドロップしてもPNG画像画像のまま（つまりキャッシュされた画像を使っているらしい）。
７．そこで、TBのManage images…画面で、このキャッシュ画像をDELしたのち、別のPNG画像画像をWindows Photosで表示し、TBにあらためてMP4をドロップすると、今度はこの別のPNGの画像がMP4画像として表示されることに。
８．この誤画像をDelete from Database してから再度MP4をドロップしても画像はキャッシュされたもののまま。＜添付ファイルの説明＞
01.png 枠で囲まれている画像が、MP4を示すもので絵は昨日フォーラムに投稿したPNG画像
02.png 本日キャプチャした Mnage images…画面を保存したPNG画像
03.Library Viewerの上側の画像が、本日あらたにドロップしたMP4を示す画像。絵が本日作成したPNG画像のものに変わっているのがおわかりいただけるでしょうか。
04.png MP4動画のアイコン。絵が明らかに違うでしょう？よろしくお願いします。
Attachments:
トピック内の案件（課題）が混濁してしまい、ご面倒をおかけしていますが、当方の件はこれで終了としますので。
（hiro様ご投稿の内容は、管理者様にて別トピックとして切り出していただいたほうが、のちのち他の閲覧者が参照するのに便利かもしれません。ご判断にてご処置をお願いします。）
肉山のほうの結論。
【結論】
結論をまず申すと、本件は忘れてください。ジタバタしただけで終了。
おそらく当方のハードェア（およびそれに関わるOSの振る舞い？）のせいだと思われます。【検証手順】
１．OS立ち上げ
２．HD（G:)接続（USB V2ポートに刺したV2対応ハブ経由）
３．TB起動
４．TBがDBの登録作業を始める
５．ファイルが沢山あるので、ある程度のところでTBを終了
６．HDのとりはずし
７．TB起動→DB登録は消えない
８．TB終了
９．その後HDを再接続しようとごちゃごちゃやっていると、OS（ExplorerとStorage－Disk Management）がG:ドライブを表示しなくなる。
※ステータスバー内の機器とりはずしアイコンには同ドライブの製品名が表示されているがアサインされているべきドライブレターは表示されていない。つまりOSはハードウェアとしてHDが接続されたことを認識はしているがOSが認識するドライブとしてアサインしていない。
１０．同HDをUSBハブ経由しないで直接USB V2ポートにつないだところOSが認識しG:をアサインした。上記のような現象は、今日はじめて出た。
⇒ゆえに、ハブとHDとの相性問題がTBの振る舞い（OS経由のドライブ認識）に影響を与え、誤認識させたものと結論づけることとしたいと思います。。。
昨日から、おそらくハブとHDとパソコンの相性悪い兆候が出始めていたのではないかと推察します。おそらくハブが腐り始めているのだと思います。。。ハブ酒になる一歩手前。
安物のハブ（実売で700円くらいのもの）で、1年以上使っているので、そろそろお釈迦なのかもしれません。
なにも高度な機能を持たないハブだと思うので、そのハブがHDをの接続状態を記憶保持しているとか、ハブの状態をOSが記憶しているとか、そういうことはないものだと想像しますが、機械やOSの素人がいろいろ斟酌してもしょうがないので忘れることとしたいと思います。ちなみに、ハブは下記の製品です。
サンワサプライ USB-HCS307BK
よろしくお願いします。
OSのStorageーDisk Management画面では、
Gドライブは接続されてない（認識されてない）状態が示されてたと思うので、面妖なと思うのですが。。。
いずれにしても、あす同じようなことをしてみますG:ドライブの登録が消えた状態でそのまま置いておかれたら(あるいはTuneBrowserを再起動したら)、再度G:ドライブの内容がTuneBrowserに登録されたのですよね?
否です。
消えてそのままです。
消えて以後は、まだHDをつないで登録処理を実行していません。
あすそれをしてみて挙動を報告します
検証のための有効な手順があれば教えておいてくださいちなみに、そのパソコンはだいぶ初期のUSB V3ポートがついているらしく、そのポートにHDをさしても認識しなかった(もうひとつのUSB V2ポートは認識するのでいままでそのポートを使っていたところ、きょうはじめてたまたまUSB V3ポートにつないでみたらだめだということを知った）という経緯もありました
ちなみに２、関係ないと思いますが、一連の操作は次のとおりです
１．HD接続→TB起動・DB同期→TB終了→HDとりはずし→TB起動→DB登録消える
２．USB V2ポートにハブがつながっていて、その先にHDをつなげているのですが、そのハブにもう一台のHDをつないでHD-HDでFastCopyを使って内容同期しようとしたら、同じポート内に２台のHDをつないでいるとIOエラーが出ることがわかったため、初めてV3ポートにHDを接続してみらた認識されなかった
３．それでHD同期をあきらめて、V3ポートとV2ポート（のハブ）からHDをとりはずした
４．たまたまMP4ファイルをTBでもMP3変換できるはず、いちど試してみようとHDを繋がない状態でTBを起動したら、DB登録が消えていくことに。※上記のようなディスク認識やIOに係る操作をしたことからOSの管理する情報にへんな情報が保持されたのかしらん？
きょう、はじめて報告した現象が出て、その後はあらためてDB同期→TB終了→HDとりはずし→TB起動をしていないので、必ずなるかどうかわかりません
Gドライブをはずした状態でTB起動したら、あれよあれよという間にDB登録数が減っていって登録がなくなってしまって、目が点になりましたわ。
※添付したプリファレンス設定では、HDがないとき消さない の設定だと思うんですが。。。この現象も手元の環境ではないので、あすためして報告します
いまいる場所にはないパソコンでのことですので
明日ためして報告しますちなみに、MP4ファイルもPNGファイルもデスクトップにおいた状態で作業し起こった現象ですので、おそらくイメージの管理を開くとデスクトップ上にあるということになると推察します
もしlame指定わすれが原因なのであれば、できれば、初回MP3変換のときは、処理をはじめる前にlame.exeを場所指定せよとゆぅてもらえますと、ありがたいですね。。
結構な時間、処理が走ってからエラー、といわれたから。。。あ、Error : File does not exist: lame.exeと出ていますね
自分で用意したlame.exeの場所を設定するんですね？
そういえばFB２KでもはじめてMP3変換するときにlameのありかを聞かれた気が。。どこで設定するんですか？
x64TBにはx64lamegが、x86TBにはx86lameがいいですか？訂正
clipboxというアンドロイドアプリでDLでした
画面に表示されている画像は、質問で添付したTBのプリファレンス画面ですが、右クリックしてプロパティをみると、MP4動画の情報が正しく表示されます
以前に、下記のように教えていただきましたが、、
————————————-
ドライブがいなくなってしまった場合、既定の設定では、一時的にマウントが外れただけと考えて、楽曲の情報は削除しないようになっています。
この設定を変更するには、設定画面の、
左側のツリー:「基本の設定」
右側の項目 :「登録に関する詳細設定」-「ドライブごと存在しない場合は消去しない」
この部分をNoにしていただくと、削除されるようになります。———————————-
本日、外部USB HD(G:)をつなげてDB同期→TB終了→ 外部HDをとりはずす→TBを立ち上げる→TBがDBエントリを削除してしまう という動きがありました。これは仕様どおりでしたでしょうか。
監視フォルダ G:\Files\FLAC;G:\Files\MP3
TB版：4.3.0.1358
プリファレンスの設定は添付のとおりです
宜しくお願いします
Attachments:
1.事象が出ているアルバムは、前回も含めて、新規登録でしょうか?
はい、そうです
2.動的タグ “_ALBUMARTIST” の設定は変更されていますでしょうか? (既定の設定は “ALBUM ARTIST; ALBUMARTIST” です)
していません
3.次回、同様の現象が発生した場合、TuneBrowserを再起動せずに、そのアルバムに対して右クリックから「データの更新」を行ってみてください (お願い)。
承知しました。ただ、ご指示の操作は私のところで実施してみたけど変化が起こらなかったようにうっすら記憶しています。うっすらです、確証はありません。
4.この現象は、大量更新中に稀に発生するとのことで、追い込みが非常に難しい状態です。
どれくらいが大量への閾値か主観的ではありますが、６万５千曲ほどが入ったHDに対して、50～100ファイルくらいを追加するといった処理をよく行います。
この現象がでるようになったのは、.1354ビルドからです。ただし、それまで気がついてなヵっただけかもしれませんが、おそらく.1354ビルドからの問題だと思われます。また、この現象は前回同様いちばんマイナーレビジョンの適用を行っている機械でのみ出ています。もっとも、この機械の使用頻度が一番高いので問題が出る／気がつくだけなのかもしれません。
念のため事象をまとめると、
FLACファイルのみで発生。→いまのところはそうです
タグがまちがった値になるのは、いつもArtist系のタグ = Tree ViewもAlbum Viewも両方ともおかしい。→そのようです。問題が出ているときは、ぴんくいろのアーティスト名が表示されてないという事象がみられますね
大量更新中に発生。→上記のとおり
TuneBrowserを再起動すると正常化する = ファイルからは正しく読めて、データベースにも正しく記録されている。→そうです今後も品質向上の助力となれれば幸いです。
よろしくお願いします。
4.3.0.1357です
名無し分類再現しました。（前回のとは別のアーティスト、アルバムで、本日新規に追加したもの）
添付０１の現象が出て、TBを再起動したところ名無し分類がなくなりました。
スクリーンショットでは撮り損ねましたが、ステータスバーのReadyの位置に、前回と同様[]のような表示がでていました。
必要であれば楽曲ファイルをお送りします。
よろしくお願いします。
Attachments:
承知しました。
他の明示的な諸課題にご注力ください。
よろしくお願いします。
これは、ダムユーザの根拠なき仮説ですが、5ツのうち2ツ名無し現象が出たPCは、いちばん頻繁にTBの版（マイナーレビジョン）更新をしクロールに係る検証をしている機械ですので、DBに一部コラプションがあったのかもしれないという視点もあるかと。TBのファイルからのタグ情報読み出し処理に問題ありの視点でなく、DBがくちゃけてたのではとの視点。
寝言です。
よろしくお願いします。
>ちなみに、nikuyamaさんのところではもう二度と再現しないですよね?
いまのところ再現しておりません
よろしくお願いします
分類おたくですみません
よろしくお願いします
現象が出たPCでは、そのとき、右下のペインのアルバム名の上にピンク色のアーティスト名が表示されていないものがあると申しました。（その表示されていないものが、名無しに分類されたもの）
で、別PCでみると、５ツのアルバムすべてについて、右下ペインでアルバム名の上にピンク色のアーティスト名が表示されていました
でで、現象が出たPCでTB再起動によって５ツ正しく分類された状態で右下ペインを見ると、５ツともアルバム名の上にピンク色のアーティスト名が表示されています
参考になるかどうかわかりませんが、気づいたことをお伝えしておきます
よろしくお願いします
265MBでも同じエラーになるので、データ便で送りました。
DLのURLはメールにてお送りします。
データ便したファイルは、１ツのZIPに各５アルバムの１曲めだけをいれています。
よろしくお願いします
昨日申した、「別PCでは正しく５ツ格納されていた」件ですが
このPCではだいぶ前のTB版で１ヶ月くらい前のHDの状態でDB同期したものに対して
昨夜TBを最新ビルドにして自動クロールしたら対象アーティストの箇所に５ツのアルバムが入っていたものです。ですので、５ツのアルバムのうち２ツにタグの不整合・ゴミなどがあったのであれば、この同期でも現象が出たPCと同じようなツリー表示になるのではないかと思います・・・
さきほど、もう一度フォームから再送信してみましたが、またも同じくFile is not selectedが出ました。
２１．６GBです。大きすぎますか？
もし大きすぎるなら、わけて送りますので１送信時の最大許容サイズをご教示ください。
よろしくお願いします
TAGSCANNERはダンプ対象とするアイテムを自分で編集できますので、先のダンプは下記が対象になっています。
$document_open
$select %_index%,0
“%title%”;”%album artist%”;”%albumartist%”;”%artist%”;”%album%”;”%track%”;”%year%”;”%genre%”;”%_length_sec%”;”%_filesize%”;”%_filedate%”;”%filepath%”;”%filenameext%”
$endselect
$document_closeエクセルはこのソフトが吐いたCSVを私がXLSにしたもので、カラムの位置とか不要カラムの削除とかしていますので、上記の指定の順序どおりにはなっていません。エクセルの１ぎょうめは、私がつけたもので、albumartistと全小文字・スペースなしで書いたのは、私がそうかいただけです。ただ、上記指定のように”%albumartist%”と指定しているので、それに合致するタグ内容がダンプされたのだと思います。試しに、”%album artist%”という指定も加えてダンプしてみましたが、これは出てきませんでした。
さきほどご指定のフォームから送信しましたが、
完了画面でFile is not selectedと表示されています
サーバ内には、到着してますでしょうか？
現象の出ていたPCでTBを起動したまま一晩中（１０時間程度）放置していましたが、ツリーに名無し登録があるところはそのままでした（おそらくその間に自動クロールが走ったものと思いますが）。
そこで、いったんTBを終了して、すぐにTBを再起動（PCは再起動していない）してみると、名無し登録がなくなり、正しくEli Degibriというアーティストの中に５ツのアルバムが表示されていました。
ツリー部の表示更新処理に課題があるのでしょうか？
よろしくお願いします。
別PCでは、正しく表示されていることがわかりました。
クロール時になんらかの条件があると起こるのかもしれません。
添付は、別PCのもの。
よろしくお願いします
Attachments:
調べてみましたが、スペースがはいっている、何も入ってない、先頭にスペースが入っている などの状況はありませんでした
参考として、TAGSCANNER（https://www.xdlab.ru/en/）というソフトでタグをダンプしたものをお送りします。黄色で塗った部分が、TBで名無しに分類されたものです。
※解決するまで、対象アーティストのタグメンテは止めておきます
※必要であればFLACファイルそのものの参考提供も可能です
よろしくお願いします
Attachments:
続報します
さきほどのツリーにいないといった２ツのアルバムについて、そのカテゴリの一番上に「名無し」で登録されていました
これらのタグ付けをいろいろやってみて正しくアルバムアーティスト名のところに収まるか試してみてもよいのですが、まずはご意見（とご指示）をいただくまで、触らずにおいておきます。
よろしくお願いします。
Attachments:
次の手順で、ツリービューに反映されない事象が発見されました。
１．DB同期済みのHDを接続しWindowsに認識されていることを確認後TB（.1354ビルド）を起動
２．アーティスト別に管理しているサブフォルダに新アルバムを追加→自動クロールされたと思ったもののツリービューに反映されない
３．おかしいと思って、そのアーティストのサブフォルダを対象に手動（強制）クロールしたが、ツリービューに反映されない
４．TBの右下のペインにはそのアーティストのサブフォルダに格納されているアルバムがすべて（５つ）表示されているが、ツリービューには表示されていない
５．右下のペインのアルバム表示で、左の２つはアルバム名の上にアーティスト名が表示されていない（その２つについてツリービューに表示されていない）。その２つのタグのつき方は、添付２つ目のとおり。
アーティスト名：Eli DegibriかEli Degibri Trio
アルバムアーティスト名：２つともEli Degibri
音声形式：FLAC
TBのバグでしょうか、タグの付け方がまずいのでしょうか？
たまたまこのアーティストで気が付きましたが、他のアーティストについても同様のことが生じているような気がします。
※新トピックスにしたほうがよければ、貴殿にて移動をお願いいたします。
よろしくお願いします
前記の
【古い登録が残る場合の手順】
１．TB4.3.0.1352以前の版で、過去のHDの状態（状態１）でDB同期
２．TBを4.3.0.1352版にして、更新されたHDの状態（状態２）で自動クロール→古いDB情報が一部残る
３．TBを4.3.0.1353版にして、さらに更新されたHDの状態（状態３）で自動クロール→古いDB情報が一部残ったままとなるの環境に対して、1354を適用し、30ファイル程度の更新のかかったHDを装着し自動クロールに任せたところ、古い登録が削除され、本日の30更新についても新規登録されました。
クロール速度、ツリー表示への反映速度については、不満足を感じない程度である（ただし主観）と思いました。
しばらくHDの更新にともなって、観察してまいります。
ありがとうございました。
ありがとうございます
次の先行版（あるいは正式版）のビルド提供の日程目処がわかればご教示願えれば幸いです。そのタイミングに、HD更新のDB反映のタイミングを合わせるようにすれば検証に資することができるので。。
よろしくお願いします。
改修でご苦労をおかけしているところ、もしかするとムカつかせてしまうかもしれない事象について報告致します。。
昨夜遅くに自宅の別のパソコンでTBをいじっていたところ、自動クロールで過去（小文字→大文字ディレクトリ名変更前、ジャンルタグ変更前）に登録されたDB登録情報が削除されない件につき、次のような条件で起こるのではないかと推察できる事象が見られました。
【古い登録が残る場合の手順】
１．TB4.3.0.1352以前の版で、過去のHDの状態（状態１）でDB同期
２．TBを4.3.0.1352版にして、更新されたHDの状態（状態２）で自動クロール→古いDB情報が一部残る
３．TBを4.3.0.1353版にして、さらに更新されたHDの状態（状態３）で自動クロール→古いDB情報が一部残ったままとなる【古い登録が残らない場合の手順】
１．TB4.3.0.1352以前の版で、過去のHDの状態（状態１）でDB同期
２．TBを4.3.0.1353版にして、さらに更新されたHDの状態（状態３）で自動クロール→古いDB情報は残らず新しいディレクトリ名／タグ情報に基づいてDB更新されたようにみえる
———————————————————–
参考）（状態１のHD）
ディレクトリ名 \Files\MP3\、\Files\flac\
ジャンルタグ (MP3)Jazz 、(FLAC)Soul など（状態２、３のHD）
ディレクトリ名 \Files\MP3\、\Files\FLAC\
ジャンルタグ Jazz、Soul など
———————————————————–推察するところ、ディレクトリ名対応されていない先行版を途中
に挟むと、DBの登録状態がおかしくなってしまうが、ディレクトリ名対応した先行版に直接UpgradeするとDBの登録状態は正しいものとなる、という動きのようです。よって、1353版で対処していただいたディレクトリ名変更対応は奏功しているのではないか。いずれにしても1352も先行版（テンタティブ）であるので、この問題について追求していただく必要性は低まったのではないか。（一般的には、正式版から正式版へのUpgradeで問題がでなければよいので）
上記の現象は、ある1台のPC環境で検証しただけのものであり、別のPCでも同じようになるかどうかは確証がありませんし、本当に全ファイルを対象にDB更新されたかどうかまでも確認することができません（6万曲以上あるし、あちこちのファイルについて情報更新しているので確認は事実上不可能）が、ご参考までお伝えしておきます。
いずれにしても、もっと問題点を追求なさって品質向上に努められるかどうかは、開発者さんのご判断ですので、上記は一現象レポートということで扱っていただければと存じます。
よろしくお願いします。
かもしれませぬ
今やっていただいている対処によって派生的にイロイロ治るような気もしております
よろしくお願いします
ありがとうございます、ご無理のないようにお願いします
ただ１点気になるのは、前回同期時からHDに変更がないのに、本日PCに接続してTB（新版）を起動したところ、進捗マドに
Deleted, New File 云々の更新メッセージが出たことです
これは、前回に漏らしていたということなのかな？と。
よろしくお願いします
※別トピックと関連する内容ですが、こちらのトピックに書きます
昨日とは別環境のPC（先週、ツリーに現れないアルバムがあるようだと申したPC)）のTBを4.3.0.1353にしたところ、前回クロール以降、同じ外部HDにファイル（楽曲）の追加をしていないにもかかわらず、HD接続後TBを起動すると自動クロールが走ってかなり多くのファイルが追加（DB登録）されました。
Crawler(Periodic)窓をみていると、あいかわらずある処理単位のあと一休み（3分くらいかな）して、次の処理単位がはじまる動きは相変わらず見て取れます（その一休み期間が従前バージョンより速くなっているのかどうかまでは、計測をしていないのでわかりません）
一休みにはいる前に
UL07275: 2018-02-19 10:30:56,602: 3354: TL02: Crawling all folders (Normal) has finished.
UL07276: 2018-02-19 10:30:56,603: 3354: TL02: Next normal crawl time is 2018-02-19 14:30:56
というメッセージが出ていたかどうかはわかりません（次の処理単位が走ると、前の処理単位のCrawler(Periodic)ログがクリアされてしまっているようなので。DB登録されていない（ツリーに現れない））アルバム／楽曲があったかどうかは、本日の観察ではわかりませんでした。
宜しくお願いします
動作速度については、前掲のとおりです
>新規エントリーについてのDB登録やツリーへの反映は速くなったように思います
>（ただし計測・比較をしたわけではなく、あくまで印象であります）
フォルダ構成は次のとおりです
前の構成とジャンル設定：
e:\files\flac\xxxxxxxx
(FLAC)Jazz Sax
(FLAC)OST
など
e:\files\MP3\xxxxxxxx(MP3)Jazz
(MP3)Guitar
など
今の構成とジャンル設定：
e:\files\FLAC\xxxxxxxx
Jazz Sax
OST
など
e:\files\MP3\xxxxxxxx
Jazz Sax
OST
など ※MP3ファイルのアルバムのアルバム名の先頭に(MP3)とつけて識別するように方針を変更した
今の管理フォルダ設定
e:\files\FLACと e:\files\MP3
楽曲形式はFLACフォルダのものはFLAC、MP3フォルダのものはMP3
ジャンルを編集したのは、メインはMusicBee、TuneBrowserで少々。（今回の問題（疑念）の対象となっているファイルはMusicBeeで編集のものと思って差し支えありません）
ジャンル番号かジャンル文字列のどちらを書き込んでいるかはわかりませんが、私の場合独自のジャンル名を使っているので、文字列を書き込んでいるのだと推察します
添付画像のツリー部で、先頭に（FLAC）とか（MP3)とかついているのは、前のジャンル設定のときのもので、今はその下の頭に（XXX）が付かないジャンルに変更しています。しかし、（XXX)の登録が消されていません。
今日の環境では、認識されていないファイルがあるかどうかわかりません（気が付きません）
※認識されてない環境は別場所にあるPCであすなら確認できます
Attachments:
自動クロールにて、
①古いディレクトリ名時代の登録について、新版でも消されることはありませんでした（前のレポート時と同様の状態）
②また、ディレクトリ名は変更されていないが、タグ編集でジャンルが変更されているものについてもそれが反映されていません（前のレポート時と同様の状態）
①について、新ディレクトリ名に基づく新DB登録はされています
②について、新タグ情報（ジャンル名）に基づく新DB登録はされていません
もしかすると、私がそういう仕様であることを勘違いして、おかしいおかしいと騒いでいるだけでしょうか？
新規エントリーについてのDB登録やツリーへの反映は速くなったように思います（ただし計測・比較をしたわけではなく、あくまで印象であります）
訂正！すみません！
さきほどお送りしたアルバムは、当方のタグのつけ間違い（ジャンルをつけ間違っていた）でした
「補足２」についてはご放念ください
補足２です
クロールで検知されないアルバム（フォルダ）について、FB2Kでも同じように検知されていないようです。フォルダか各ファイルの属性とかタグ記述に問題があるのでしょうか？
そのアルバムフォルダをFB2K、TBに手でドロップしてみると、ちゃんと再生されますし、タグ情報なども問題ないように見えます。。。
おそらく、他のアルバムで検知されていないものも同じ理由かと推察されます。
参考として、FB2k、TBで検知されないアルバムフォルダを添付します。（個人的な鑑賞又は開発の目的のみに使用してくださいネ）
補足
別トピックでは、「編集」できました
補足です
\アーティスト名フォルダ
アルバム１
アルバム２
アルバム３
とHDに入っているのに、ツリーにはアルバム１と３しか表示されていない、その状態のフォルダに対して、新しいアルバム４を追加したらツリーにアルバム１、３、４が（すぐに）表示された。アルバム２が検知されていないのに、新しい４は検知されたようです。
むむぅ、でしょう？
はい、GUI（ツリー表示部分）への反映がもぅちと速くなると使いやすいです
もしかすると
１．実際は、ディレクトリをまたいで、途切れずにクロール処理しているものの、クロール進捗情報窓（半透明のやつ）が一定時間で消えて何かのタイミングでまた表示再開されるので、処理が途切れているように見えているだけでしょうか。（以前に、進捗窓は放っておくと消えるというお話があったように思いましたので）
だとすると、それを検証するために
２．TBの１起動単位中に処理された（ファイル単位の）全クロールログを取得する方法はありますか？それを見れば、クロール処理が途切れたか途切れていないかを時間軸で確認できるから。
よろしくお願いします
>まだ本当にそのような動作をしていますでしょうか?
LogView窓と、クロール状態表示窓（半透明のやつ）をチラチラ見ている限り
そのように思われます
そういう意味では、こちらから「印象」でレポートされても開発の効率が悪いでしょうから、
なにかテストシークエンスと計測ツール（あるいは手順）みたいなものをご提供いただければ
貴殿の参考により資するものになるかと思います失礼しました
前記載の
「どうも、いまいちのようです。
前にクロールしたときから、同じHDでクロール対象のフォルダ名を変更していると、ツリービュー（つまりDB)にある以前の登録が残っているように思われます。
新しいディレクトリ構造のエントリーは新しくツリービューに反映されているものの、古いエントリーも残っているようです。ただし、過去のものがきれいに全部残っているわけでもなくて、新しい構造にともなって消されたものもあるように見えます（対象ファイル数が多いので、詳しくすべて調査することはできないので印象です）」
の繋がりとして本日記載しました
速度については・・・
目視での感覚でしか申しようがないのですが、
従前より変更検知の速度は上がっているようには感じます
（しかしながら、FB2Kのようなスルスル感までは程遠い印象です、ただしこれは言っても詮無い比較なので今後申しますまい）それと、これも印象ですが
HDがPCに接続ずみの状態でかつTBが起動している（つまりHDをモニタリングしている）状態でHDに変更を加えたときの検知反応速度はこれまでより大分と速くなった「気がします」が、別PCで変更ずみのHDをPCに接続してTBを起動したときの検知速度はだいぶ以前の版よりは早くなったもののもう少しなんとかなならんかなとの印象です。これも比較してもしょうがないのですが、FB2Kではいろいろなディレクトリに変更がかかっていてもつながってスルスルDB更新してくれるのですが、TBの場合はあるディレクトリについて更新したらちょっと休んで別のディレクトリについて更新して、また休んでみたいな動きをします
まぁ、忘れておいて他の作業をしていればいいのですが、気になりだすと「もう更新終わったかいな、いつ終わるんかいな」ときになってしまうので・・・
更新終了する前にTBを終了するのもアレな気がするので、LogViewでクロール終了してることになっているかを確認したりして、僕ってけなげなユーザーと思ったりして。一定量の変更に対するDB更新のトータル速度については、速くなったかどうかはよくわからないというのが正直なところです。ファイル更新量によって都度違ってくるから。
ある一定の更新に対してDBを新規作成にして、旧版と新版で速度比較してみればいいのですが、そこまではちとめんどくさい。。
よろしくおねがいします
残念ながら状況改善せずです。
詳しく申すと、こういう手順です。e:\files\flac\xxxxxxxx
e:\files\MP3\xxxxxxxx
というディレクトリ構造でクロールしDB登録していたその後、ディレクトリ名を次のように変更するとともに、全ファイルのタグをつけ直した（つまりファイルすべてに変更を加えた）
e:\files\FLAC\xxxxxxxx （ディレクトリ名変更、タグ変更）
e:\files\MP3\xxxxxxxx （タグ変更のみ）更新のかかった外部USB HDをPCに刺しTBを起動すると、更新内容を検知して新ディレクトリ構造に従ってDB登録を自動で行ってくれたものの、古いディレクトリ構造に基づくエントリは削除されていない（ツリービューに表示されたまま）
古いエントリーからアルバムを選択して再生してみるとファイルの置き場が変わっているにもかかわらずエラーとならず再生される。おそらく、ディレクトリ名の変更は\flacから\FLACへと大小文字の変更であり、TBはUpper・Lowerの違いを区別していないからではないかと推察される。同時にDBのエントリ更新すべき際にもUpperに変更されたディレクトリ名に係る登録について、それが無くなったものと判断せずに残してしまうのではないか。新しいUpperディレクトリ名のものは新規のものとしてこれはこれで新規登録している。よろしくおねがいします。
祝復活🎌
明日、試して報告致します。
あきません
寝といてください
これも同類でしょうか？
LogViewの右端のアイコン２つが表示されてません
マウスをホバーすると、ボタン部が浮き上がってかつツールチップが表示されます
押せます、ログビューは閉じます。
皆さんの書き込みを拝見して、いま気が付きました。
Attachments:
どうも、いまいちのようです。
前にクロールしたときから、同じHDでクロール対象のフォルダ名を変更していると、ツリービュー（つまりDB)にある以前の登録が残っているように思われます。
新しいディレクトリ構造のエントリーは新しくツリービューに反映されているものの、古いエントリーも残っているようです。ただし、過去のものがきれいに全部残っているわけでもなくて、新しい構造にともなって消されたものもあるように見えます（対象ファイル数が多いので、詳しくすべて調査することはできないので印象です）
よろしくお願いします
あ、ジャンルーアーティストーアルバム で、 ジャンルーアルバムアーティストーアルバムで表示されていました。
4.3.0で、なんとなくこれまでよりは自動クロールの反応が速くなったかなぁという気はしていますが、確証はありません。
具体的にどのようなケース（自動クロールの始まる（感知されるまでの）時間、自動クロールが完了する時間、手動クロールも関係あり？ など）に気をつけて観察しておけばよいか仰っておいていただけると、そのようにし、報告致します。
関連質問で恐縮ですが、
１．手動クロールの実行速度も改善されていますか？
２．手動クロールをバックグランドで実行するオプションのようなものはできないでしょうか（手動クロール中も他の操作をしたい・・・） ※原理的に無理な話かもしれませんが。。。
よろしくお願いします
ErrorFillesのダイアログで対象ファイルを全部範囲指定してCheck Fileしたら、
ちゃんとレポートされました
ありがとうございました
ありがとうございます
さっそくやってみました
Stage: Checking files
=== Checking file: [E:\Files\flac\02_Bass\Chuck Rainey\David T. Walker Chuck Rainey David T. Walker Band\03 Feel Like Making Love.flac]
Reading file: [E:\Files\flac\02_Bass\Chuck Rainey\David T. Walker Chuck Rainey David T. Walker Band\03 Feel Like Making Love.flac]
Reading spec from file: [E:\Files\flac\02_Bass\Chuck Rainey\David T. Walker Chuck Rainey David T. Walker Band\03 Feel Like Making Love.flac]
Error: Fail to call FLAC decoder for FLAC::Metadata::Chain.
Error: Reading spec failed: [Error ]: [E:\Files\flac\02_Bass\Chuck Rainey\David T. Walker Chuck Rainey David T. Walker Band\03 Feel Like Making Love.flac]All tasks have done. Detecetd some error.
Stage: Checking files
=== Checking file: [E:\Files\flac\04_Funk\Ohio Players\Ohio Players – Greatest Hits (1999, Spectrum)\01 – Love Rollercoaster.flac]
Reading file: [E:\Files\flac\04_Funk\Ohio Players\Ohio Players – Greatest Hits (1999, Spectrum)\01 – Love Rollercoaster.flac]
Reading spec from file: [E:\Files\flac\04_Funk\Ohio Players\Ohio Players – Greatest Hits (1999, Spectrum)\01 – Love Rollercoaster.flac]
Error: Fail to call FLAC decoder for FLAC::Metadata::Chain.
Error: Reading spec failed: [Error ]: [E:\Files\flac\04_Funk\Ohio Players\Ohio Players – Greatest Hits (1999, Spectrum)\01 – Love Rollercoaster.flac]All tasks have done. Detecetd some error.
上の１つ目は、たしかにアルバムの３曲めが壊れていました。（１，２曲め、４曲目以降はこわれていませんでした）
２つ目は、アルバムの１曲めが壊れているということで、そのアルバムのフォルダを調べたところ、１曲めはこわれていて、その他（２から１７曲目）もすべて壊れていました。それであるのに、TuneBrowserのCheck Files機能ではレポートされませんでした。１曲めがこわれていると、その後はチェックしない仕様になっているということでしょうか？それともバグかなんかでしょうか。
よろしくお願いします。
そうでしたか、わかりました。
それはそうとして、error reading fileの事由を知ることはできますか？
ファイルが壊れてる、ヘッダがおかしい、タグ情報がおかしい など。
おかしいファイルはできれることなら修正したいので。
よろしくお願いします。
よくわかりました
ありがとうございました
判定基準はどういうものですか？ 曲数（データ量）と利用可能メモリとか？
そうであれば、たとえば、状態灯を押して自分でAllモードにしたときに、判断の閾値を超えそうなら「できませんのでSモードにします」みたいなメッセージがでればわかりやすいかと思いますが、まぁ、そこまでなさる必要もないようにも思います。
ところで、RamDecodeのメリットとは、どういうものでしょうか？ IO負荷の低減とか、HDアクセスノイズの低減とかですか？
わかりました。PC、HDD、DACの組み合わせをためしてみます。
ケーブルノイズの可能性は、本件については関係なさそうな気が。気休めにフェライトコアもつけてますけど、これはホントに気休めですね。
わかりました。
なるほど～ CPUが結構喰っているのですか、私などは昔のコンピュータのイメージを引きずっているので、I/O速度の限界に塞がれているのかな、、などと思っていました。
とまれ、違う次元のやり方が天啓のように現れるとよいですね！
もしかすると、断捨離だったりして。。。
仕様のご説明をありがとうございました。
わたしのようなソフトお宅（ただし、開発はできないで使うだけ）は、内部でどのような振る舞いをしているかがわかれば、それでスッキリして現状に合わせますので、本件については当分のあいだ手動クロールすることで問題ありません。
たしかに、TuneBrowserは、タグ情報などFB2Kに比べても豊富にサポートされていて、その他情報も同ソフトに比べて相当にリッチなので、速度とのトレードオフになることについては、悩み多いところでしょうね。
ファイル読み込みと同様に、TBの起動時や終了時にも、それなりの時間がかかることから、いろいろ豊富な情報を読み書きしてるんだろうな～と微笑ましく動作を見守っておりましたので、除々にではあれパフォーマンス改善が進まれることを期待します。
それにしても、LogView(Event)表示機能を作成していただいたお陰で、解決が早まり助かりました。ありがとうございました。
FastCopy同期終了後1時間を過ぎたころ、自動検知・更新の情報ウインドウが表示されて
ツリービューの数値もズコズコと増えました。LogView(Event)をみると行が増えるのが止まっています
どうやら、Reading をするのに相当の時間がかかて、それが終わってから更新処理が走っているイメージです。（作者を差置いて素人の想像をしてすみません）
ここで、ほぼ結論。
「自動検知・更新がかからない場合がある」というのは私の勘違いでした。すみません！
もっと、じっくりと物事に対処できる人間になれるよう精進したいと思います。(_ _;)
※ある程度の数の更新がかかっているときは、自動検知高速モードとして手動クロールと同様の動作をするスイッチがあってもよいかも。今日はMP3ファイルの削除300くらい（かな）、FLACファイルの追加400くらい（かな）だったわけですが、私の環境では、手動クロールであれば5分かからないです。自動検知の20倍以上速いですね・・・（悲報）
いま、FastCopy同期終了後40分ほどたっていますが
LogView(Event)が遅々としてTl03: Reading folderをレポートしています
そして、ツリービューの数値にも変化が出ています（しかし、ツリービューの数値はFB2KのようにほぼHDD更新とリアルタイムに反映されるのに比べて、TBの場合はある程度バッファリングしてからポンと加算・減算して数値更新しているように見えます）
どうやら、自動検知・更新機能より、手動クロールのほうが速くDB更新処理できる（ツリービュー情報も更新される）ようです。総ナメの手動クロール機能のほうが、部分ナメの検知機能より速いというアイロニー(T_T)かな？
今日、もう一度ためしてみての考察です
１．ポータブル－据え置き 同期前 83/60684
２．FastCopyで同期
３．同期終了時 83/60684 しかし、このときLogView（Event)をみていると、すこしづつイベント行が増えていっている。つまりある程度の量が検知対象になるとTBの処理が遅いため反応してなかったように見えているだけではないか（証左として、ゆうべやったときは、２時ころからFastCopyの同期を始めて寝落ちして５時半頃みたら数値が増えていてその後手動クロールしても同じ数値だったから）
ただし、LogView(Event)が増えていってはいるが、ツリービューの数値は83/60684のままである。TBのツリービューの更新（情報反映）にかなり時間がかかるということ？
今回FastCopyでの動機が終了してから１０分程度経っているがツリービューの情報は更新されていない状態ですが、このまま数時間放置（手動クロールをかけない）してみて改めて報告します。
※上記仮説が正しいとするなら、やはりTBの検知更新速度の改善をご検討いただきたいところですねーー。。
本日のソースHDDの変更概要
MP3フォルダのフォルダ／ファイルを相当数削除
flacフォルダにフォルダ／ファイルを相当数新規追加
１．PC起動
２．TBを4.2.4.1346へ更新
３．TB起動
４．ツリービューの値確認＝82/60262
５．TB起動したまま、FastCopyでポータブルHDから据え置きHD(管理対象）へファイルを追加・更新 → 83/60684に
６．引き続き、マニュアルクロール実施。83/60684のまま
今回は、ディスク同期中に自動更新されたようです。
わかりました
きょうは、仕事の関係でのんで帰るので
不覚になっていなければ、26時頃試せると思います
（きょう、いい感じでHDをいじっていたので）
新レビジョンの公開はいつごろになりますか？
（そのときに、いい具合にテスト対象にできるHDDの状態を準備するため）
A.のこともあれば、B.のこともある だと思います
当初は、まったくTBが反応してないのかなと思っていましたが
先日よりログビューのマドを見ることを覚えましたので
それとツリービューを見比べながら観察していると
ツリービューがちょこちょこ増加しているようにもみえます
ただ、ずっとみてるわけではないので、確証はないです
関係ないとは思いますが、
ポータブルのWestern Digital My Passport 3TBはexFat
据え置きのBuffalo External HDD 3TBはNTFS
でフォーマットしています。Allocation Unit Sizeは、それぞれの形式でのフォーマット機能実行時の標準値です。
ただ、ポータブルHDDだけで完結する場合（そのドライブ内でフォルダ／ファイルの移動）でも、ポータブルから据え置きへFastCopyなどで同期した場合でも起こる現象なので、フォーマット形式は関係ないとは思います。
ご参考まで。
残念ながら改善がみられないようです
１．PC起動
２．TBを4.2.4.1345へ更新
３．TB起動
４．ツリービューの値確認＝81/60026
５．TB起動したまま、FastCopyでポータブルHDから据え置きHD(管理対象）へファイルを追加・更新 → TB反応せず（ログ０１）
６．引き続き、マニュアルクロール実施。ツリービュー更新される（82/60301）(ログ０２)
※性能関連パラメータは触っておりません
以上です
使用PCは、ThinkPad X230であり、そこそこの性能ではあります
ちなみに、PCの性能について言及したのは、別イシューです（WASAPIイニシャライズ問題の件）
テストできました
【テスト内容】
管理対象としている更新のかかったポータブルディスクを差し込んだ時点で、すぐに検知とツリー更新が始まりDBを正しく更新する（ツリービューに反映する）かどうかのテスト
【環境】
昨日使用したWinタブレット（昨日ポータブルHDDでDB更新した状態。その後HDDをには変更が加わっている（追加・タグ編集））
【結果】
問題なく自動認識・更新され、DB（ツリー）の数値も正しく思われます。
【手順】
タブレットを起動
HDDを刺さずに、TBを起動 （81/59751)
HDDを刺しDドライブとしてOSが認識（このタブレットでのTBの管理ディスクレターはD）
ほどなくしてTBがディスクの挿入を検知しDBの同期を開始、２０分ほどかかって正しいと思われる数値がツリービューに表示（81/60012）※手動クロールはかけていない
以上です
質問
TuneBrowserでは、管理対象ドライブの把握と識別にあたって
OSからアサインされているドライブレターのみを用いておられますか？
それとも、ボリュームラベルやハードウェアIDなども併せてチェックしておられますか？
もしドライブレターのみであれば、手動でレターを書き換えるなどして比較的容易に前項１つめのテストを行うことができるかと思いますので、お尋ねしました。
更新のかかったポータブルディスクを差し込んだ時点で、（そのディスクを管理対象としている場合には）すぐに検知とツリー更新が始まり
この点は、TuneBrowserの動作は(4.2.4では)問題ないと理解していますが、合っていますでしょうか.→TBでこの使い方を意識してやったことがないので曖昧ですが、おそらく問題ないと思います。やってみる機会があって問題が見受けられた場合は改めて報告致します。
あるいはポータブルディスクから管理対象としている据え置きディスクにFastCopyやエクスプローラで同期をかけた
今回、問題となっているのは、この点ですよね.→左様です。この場合（で該当フォルダ/ファイル数がそこそこ多い場合）は、ほぼ毎回起こります。
>更新されたファイル/フォルダ群に対して「検出できないときもある」というのは、状況によってまったく無反応のこともあれば、調子よく検出できることもある、というように理解していましたが(なので起動時のエラー検知を気にしていました)、
私も、これまでは、自動検知がすぐにされずにツリーが増加していかないなという程度の気づきだったので、「検知されていない」という表現で報告さしあげていたわけですが、昨夜LogViewを見ながら確認してみると、TBが変更追加の検知は行って、ある程度ツリーに反映はしているものの完璧ではないという現象なのではと認識した次第です。他ソフトと比較して語ってしまって恐縮なのですが、Foobar2000では、更新のかかったポータブルディスクを差し込んだ時点で、（そのディスクを管理対象としている場合には）すぐに検知とツリー更新が始まり、あるいはポータブルディスクから管理対象としている据え置きディスクにFastCopyやエクスプローラで同期をかけた時点ですぐに検知とツリー更新が始まり、またいずれのケースでも取りこぼしもなさそうに思えるため、TBの動作（認識の速度、更新の完全さ）についても同様の振る舞いを無意識に期待していたのかもしれません。
>それであれば、原理上、大量更新発生時には取りこぼすケースというのはどうしても発生します。だから仕方がないと居直るつもりはないのですが、あとはいかに取りこぼしを減らすか(同時に更新を処理する時間を少なくするか)という程度の問題になります。
内部ロジックが異なるためなのでしょうが、自動検知・更新では取りこぼしがみられるものの、手動Crawlであれば、おそらくほぼ取りこぼしなくDB更新しているように見受けられるので、そのあたりの振る舞いの統一を行っていただくことができればよいのでは、と門外漢ながら存じます。
いずれにしましても、当面は、ソースディスクに変更を加えた場合は、TBで明示的に手動クロールを実行することで運用することとしますので、実用上はそれほど問題とはなりません。機会をみて、改善のご検討をいただければと思います。（ソフト自体に取りこぼしの可能性があると分かりましたので、ある意味スッキリしましたので、その認識のもとで使用させていただきます。）
強いていうと、手動クロール機能をバックグラウンドで実行してくれるようなモードがあれば、上記のような運用においては便利ではあります。いまは、手動クロールをかけていると進捗状況のマドが出て、それ以外の操作がでいないので・・・
TB起動状態で、G(ポータブル）からH（据え置き）へFastCopyで追加・更新（同期）。
[自動検知]
Log View上では、追加・更新が次々とレポートされているが、ツリービューに反映されていないように見える。20分くらいして、ツリービューに動きがちょこちょこ見えてきたが、自動クロールがほぼ終わっても81/60077とすべてが反映されているようには見えない（画像1.gif、ログ01LogViewLog.txt）
[Manual Crawl]
そこで、マニュアルクロールを実行、81/60224となる（←たぶんこれが正しい数値）。（画像2.gif、ログ02ManualCrawlerLog.txt）
お考えください。。。
I’m gonna try!
わかりました
次回注視してみます
お考え了解しました。
いまはアンインストールしてしまったのでウロ覚えなのですが、Media MonkeyはDBの切り替えができたような気が。そのとき、便利かなと感じたので。
ところで類似の質問ですが、DBがぶち壊れたときのためにカレントDBをバックアップしとく機能ってありましたでしょうか。バックアップできたらレストアもさせろという声が出て、それはそれでめんどくさいですが。
>HドライブにUSBで接続されている “Buffalo External HDD 3TB” についてのみ、ファイル更新が自動検出されないと理解しましたが、合っていますでしょうか?
そういうわけではありません。ポータブル（Western Digital My Passport)を持ち運び先のPCに接続して、そのディスク内でワークディレクトリにあるFLACファイル群を管理対象フォルダに移動したときなどでも検知しないことがあるように思います。ただその現象が百発百中というわけではなさそうなのがお伝えするのに厄介なところです。
いろいろなケースで検知してなさそうな現象がみえるので、逐一お伝えしているので、理屈が通ってないように見えているものと思います、ややこしくしてすみません。
>先にアップいただいたログには、Gドライブをマウントした形跡はありましたが、Hドライブのそれはありませんでした。これは、言われているように、Hドライバは着脱せずマウントしたままご利用なのですよね。
ログをお送りしたときのそのPCではそうです。これは自宅に据え置いたPCのものです。(Think Pad X230)
>念のための確認なのですが、このHドライブに対する外部ソフトからの更新は、TuneBrowserはまったく反応できていないのですよね?
そういうわけではありません。できてるときもあります。（むしろできてるほうが多い。ときどきできてなさそうで、アレと思うわけです）
>以前お伝えしたLog Viewで、Crawlerタブの内容の最初の10行程度を貼り付けていただけないでしょうか? ファイル更新などは必要なく、起動後しばらく(1分程度)した後のもので構いません。
これは現象（検知されてない）が出たときにということですか？それとも手動クロールをしたときですか？それともTB起動時に自動クロールがかかったときにということですか？
わかりました
これを出しっぱなしにするようなプションスイッチは意味ありとお考えになりますか？
（CRWL灯をみとけという話もありますが）
デスクトップ上（内蔵ディスク）にテストディレクトリを作り、やってみました
C:\Users\username\Desktop\test\00_Acid Jazz
ここへ、18フォルダ、621ファイルをコピー
そして、DB作成
そして、そして、エクスプローラで、外部USB HDDから1フォルダ、15ファイルをコピー
で、自動検出更新されました
ただし、テストのため、600ファイル程度が対象。（問題の出ているディスクは65000ファイル程度存在）
以上です
M-Audio Micro DAC 24/192
WASAPI: M-Audio Micro DAC 24 192 ドライバ使用 でも
正常動作しました
4.2.4で治癒。
前版で問題のあった、
ベンチャークラフト Soundroid Typhoon
[SPDIF インターフェイス (2- USB Audio Interface)]と認識、ドライバはWASAPIドライバ使用
で、Timeスライダシークで再生とまる現象がなくなっていました。
報告まで。
さらに、次のような操作でも再現しました
TBが立ち上がった状態で、H（据え置き）上でファイルの移動・プロパティ編集などの操作をせず、まずG（ポータブル）上でプロパティ編集をしFastCopyでHへ同期
TBのDBにそのプロパティ編集結果が反映されず（というより変更が検知されていない）、明示的にManual Crawlすることで反映される
つまり、TBが管理しているドライブ／フォルダ内で直接ファイル操作するのではなく、別のドライブで行ったファイル編集等の結果をエクスプローラやFastCopyなどで管理先ドライブ／フォルダへコピーしたような場合はTBがこれを検知していないように見受けられます
-
投稿者投稿
