4.2.4(先)ファイル追加時の動作

フォーラム TuneBrowser 4.2.4(先)ファイル追加時の動作

  • このトピックには108件の返信、2人の参加者があり、最後にTikiにより2年、 4ヶ月前に更新されました。
100件の投稿を表示中 - 1 - 100件目 (全109件中)
  • 投稿者
    投稿
  • #1212

    >複数の管理フォルダをまたがった更新(フォルダやファイル移動など)が発生した場合に、どちらかの変更をとりこぼすことがある問題を改善しました.

    上記対応項目とは違う想定用法かもしれませんが、

    次のような場合に、DBが自動更新されません。

    自動検出更新、Update Database ともに期待動作しない(追加したアルバムがツリーに反映されない)

    Manual Crawlを明示的にかけると反映される

    1.4.2.4を立ち上げている状態で

    2.\AAA\というフォルダに \AAA\111 と \AAA\222 を追加

    (111と222はフォルダ(アルバム)で、これらの中にはFLACファイルが入っている)

    ・「複数の管理フォルダをまたがった更新」ではありません

    ・¥AAAは管理対象として設定されているフォルダです

    この減少は、4.2.3からあるもので、うまくレポートの意図が伝わっていなかったかもしれません。

     

     

     

    #1215
    Tiki
    キーマスター

    こんばんわ、Tikiです。

    すいません、よく状況が掴めていません。

    2.\AAA\というフォルダに \AAA\111 と \AAA\222 を追加

    このケースで問題が出ると言われているということは、111 ひとつだけを追加した場合には問題がなくて、111と222のふたつのフォルダを追加した場合に「自動検出更新、Update Database ともに期待動作しない」ということでしょうか?

    またその場合、111も222も両方登録されないのでしょうか?

    #1218

    わかりづらくてすみません

    2つとも検出されません

    #1219

    2つは、例であって、

    実際は

    \aaa\111

    \aaa\222

    \bbb\333

    \ccc\444

    \ccc\444

    のようにたくさんの追加を行ったわけですが、

    どれも自動検出されていませんでした

    #1222
    Tiki
    キーマスター

    ひとつだと検出されるのでしょうか?

    #1223

    いま、実験用に

    10アルバムほどだけを新規登録して

    そこに1アルバムを追加したところ自動認識されました

    さらに2アルバムを追加したところこれらも自動認識されました

    ・ただし、さきほどのPCとは別の環境です

    ・実験用に小さなDBで試しましたが、さきほどは65000曲ほど登録された状態のものでした

    #1224
    Tiki
    キーマスター

    ありがとうございます。

    「さきほどのPCとは別の環境」では、問題なく動作しているという理解でよろしいでしょうか?

    問題の起きている方のPCでは、(複数以前に)ひとつだけフォルダを追加したときにそもそも正しく動作するかどうか、というのは、わからない感じでしょうか?

    何度も同じ確認で恐縮です。

    #1225

    >問題の起きている方のPCでは、(複数以前に)ひとつだけフォルダを追加したときにそもそも正しく動作するかどうか、というのは、わからない感じでしょうか?

    そうなんです。問題を確認したのは別の場所(A地点)にあるPCで、いまそこから移動してしまった(B地点)のです、山本さん。(30年まえの、ザぼんちのねた)

    そのPCで1つのみ追加を試すとなると週明けになってしまいます

    ただ、その他のパソコン(Winタブレット)でも前バージョンで起こってたような気もするので、明日以降それらを使う予定があるのでためして結果をお知らせします。

    #1226
    Tiki
    キーマスター

    わかりました。ありがとうございます。

    すこし上にも書きましたが、問題のPCでは、複数フォルダの問題というよりは、そもそも更新の自動検知がはたらいていないような気がします。

    その原因は、すぐに思い当たるのは、当該のドライブがNASになっていて、NASで自動検知を行う設定を有効にしていない(既定では無効です)のではないかな、という点です。

    またもし状況がわかれば、ご連絡をお願いします。m(__)m

    #1227

    NASではなくて、USB直結のポータブルHD(Western Digital My Passport 3TB)なのですが。。。

    また、TuneBroserの設定も標準値のままです。

    #1232

    B地点のPCで現象が出ました

    手順は以下のとおりです(画面数が多くて貼り付けると掲示板がバグるのでDatadeliverからDLしてください)

    https://www.datadeliver.net/receiver/file_box.do?fb=bc407d7ca02d43988d1d2eadb6dcde87&rc=8f58e381d7c64137a2c7b6e2d9fe2de7&lang=ja

    PCには、据え置き型外部HD(USB接続)がつながっている(Buffalo External HDD 3TB →これは、持ち出し用のWestern Digital 3TBと同内容(ミラー状態))Hドライブ

    TuneBrowser 4.2.4でいったんDBをクリアし新規にDB作成

    そのBuffalo Hドライブに対して、ファイルが増加しているWestern Digital(Gドライブ)からファイルを同期(FastCopy 3.40 の同期モードを使用)

    この状態で、追加されたはずのカテゴリを見ると、TBで自動検知されておらず登録アルバムが増えていない(画面1 Krautrockジャンルを参照)これは、ファイル追加前の状態と同じ。

    管理フォルダ設定は、画面2参照

    そこで、Manual Crawl(画面3参照)を実行

    Krautrockジャンルにドライブ同期で増加したアルバムが追加された(画面4参照)

     

     

    #1233

    さらに、次のような操作でも再現しました

    TBが立ち上がった状態で、H(据え置き)上でファイルの移動・プロパティ編集などの操作をせず、まずG(ポータブル)上でプロパティ編集をしFastCopyでHへ同期

    TBのDBにそのプロパティ編集結果が反映されず(というより変更が検知されていない)、明示的にManual Crawlすることで反映される

    つまり、TBが管理しているドライブ/フォルダ内で直接ファイル操作するのではなく、別のドライブで行ったファイル編集等の結果をエクスプローラやFastCopyなどで管理先ドライブ/フォルダへコピーしたような場合はTBがこれを検知していないように見受けられます

    #1242
    Tiki
    キーマスター

    仔細の情報をありがとうございます。お手数をおかけしています。

    伺った状況から、FastCopy340を使用したときの問題かなと思い、ダウンロードして試してみましたが、やはり正常に検知しました。

    つまり、TBが管理しているドライブ/フォルダ内で直接ファイル操作するのではなく、別のドライブで行ったファイル編集等の結果をエクスプローラやFastCopyなどで管理先ドライブ/フォルダへコピーしたような場合はTBがこれを検知していないように見受けられます

    これは、Crawlerの基本職務のひとつですので、機能としてこのケースが検知できないということはないです。でもnikuyamaさんの環境では実際に検知できておらず、また、問題が発生しないPCもあることから、なにか環境の要因なのだろうと思います。

    あまりお手数をおかけするのは心苦しいのですが、問題の出ているPCで、外付けHDDではなく内蔵のHDDでは機能が動作するかどうか、お時間のあるときに試してみていただけないでしょうか?

    すこしでも要因の切り分けができれば、と期待しています。

    お時間のあるときで結構です。どうぞよろしくお願いします。

    #1246

    デスクトップ上(内蔵ディスク)にテストディレクトリを作り、やってみました

    C:\Users\username\Desktop\test\00_Acid Jazz

    ここへ、18フォルダ、621ファイルをコピー

    そして、DB作成

    そして、そして、エクスプローラで、外部USB HDDから1フォルダ、15ファイルをコピー

    で、自動検出更新されました

    ただし、テストのため、600ファイル程度が対象。(問題の出ているディスクは65000ファイル程度存在)

    以上です

     

    #1247

    #1252
    Tiki
    キーマスター

    お忙しいところありがとうございます。

    状況から、HドライブにUSBで接続されている “Buffalo External HDD 3TB” についてのみ、ファイル更新が自動検出されないと理解しましたが、合っていますでしょうか?

    (わたしも普段使いでは、USB接続の3TBの外付けHDDを使用しています。もちろんこの環境でも更新は検出されています。ですので、一概に外付けだからダメということはありません)

    先にアップいただいたログには、Gドライブをマウントした形跡はありましたが、Hドライブのそれはありませんでした。これは、言われているように、Hドライブは着脱せずマウントしたままご利用なのですよね。

    念のための確認なのですが、このHドライブに対する外部ソフトからの更新は、TuneBrowserはまったく反応できていないのですよね?

    それと、以前お伝えしたLog Viewで、Crawlerタブの内容の最初の10行程度を貼り付けていただけないでしょうか? ファイル更新などは必要なく、起動後しばらく(1分程度)した後のもので構いません。

    お手数をおかけします。よろしくお願いします。

    #1257

    >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起動時に自動クロールがかかったときにということですか?

    #1260
    Tiki
    キーマスター

    なるほど、「検出できないときもある」状況ですか…。

    ログをお願いしたのは、TuneBrowserは起動後しばらくすると、Quick Crawlを開始します。そのときに、何らかの理由でエラーが検出されていないかと考えた故です。

    ちょっとむずかしいのですが、「TB起動時に自動クロールがかかった直後」ということになります(^^;。ただ、「検出できるとき/できないときがある」のであれば、このときにはエラーは出ていない可能性が高くなってきたので、もし難しいようでしたら無理なさらないようにお願いします。

    #1261

    I’m gonna try!

    #1290

    TB起動状態で、G(ポータブル)からH(据え置き)へFastCopyで追加・更新(同期)。

    [自動検知]
    Log View上では、追加・更新が次々とレポートされているが、ツリービューに反映されていないように見える。

    20分くらいして、ツリービューに動きがちょこちょこ見えてきたが、自動クロールがほぼ終わっても81/60077とすべてが反映されているようには見えない(画像1.gif、ログ01LogViewLog.txt)

    [Manual Crawl]

    そこで、マニュアルクロールを実行、81/60224となる(←たぶんこれが正しい数値)。(画像2.gif、ログ02ManualCrawlerLog.txt)

    https://www.datadeliver.net/receiver/file_box.do?fb=aa8cf4684d454e0abcc1f4e26e37473b&rc=c1e231a909214ca3be9364df3fc02708&lang=ja

    #1294
    Tiki
    キーマスター

    nikuyamaさん、こんばんわ。ありがとうございます。

    アップしていただいたログを拝見していて、すこし状況の理解が間違っていたことに気が付きました。

    更新されたファイル/フォルダ群に対して「検出できないときもある」というのは、状況によってまったく無反応のこともあれば、調子よく検出できることもある、というように理解していましたが(なので起動時のエラー検知を気にしていました)、

    そうではなくて、大量の更新情報に対して、ときどき取りこぼしている情報がある。という感じなのですよね(ちがっていたら教えてください)。

    それであれば、原理上、大量更新発生時には取りこぼすケースというのはどうしても発生します。だから仕方がないと居直るつもりはないのですが、あとはいかに取りこぼしを減らすか(同時に更新を処理する時間を少なくするか)という程度の問題になります。

    現在の処理には、取りこぼしをあらかじめ想定したリカバリの処理も入れてあるのですが、行われているやり方(=サブフォルダを大量に更新する)では、うまく機能していないようです。

    もしこの理解が正しければ、その観点でもっと性能を上げることができないか、検討してみます。理解が間違っているようでしたら、また教えていただけますでしょうか。

    よろしくお願いします。

    #1295

    >更新されたファイル/フォルダ群に対して「検出できないときもある」というのは、状況によってまったく無反応のこともあれば、調子よく検出できることもある、というように理解していましたが(なので起動時のエラー検知を気にしていました)、

    私も、これまでは、自動検知がすぐにされずにツリーが増加していかないなという程度の気づきだったので、「検知されていない」という表現で報告さしあげていたわけですが、昨夜LogViewを見ながら確認してみると、TBが変更追加の検知は行って、ある程度ツリーに反映はしているものの完璧ではないという現象なのではと認識した次第です。他ソフトと比較して語ってしまって恐縮なのですが、Foobar2000では、更新のかかったポータブルディスクを差し込んだ時点で、(そのディスクを管理対象としている場合には)すぐに検知とツリー更新が始まり、あるいはポータブルディスクから管理対象としている据え置きディスクにFastCopyやエクスプローラで同期をかけた時点ですぐに検知とツリー更新が始まり、またいずれのケースでも取りこぼしもなさそうに思えるため、TBの動作(認識の速度、更新の完全さ)についても同様の振る舞いを無意識に期待していたのかもしれません。

    >それであれば、原理上、大量更新発生時には取りこぼすケースというのはどうしても発生します。だから仕方がないと居直るつもりはないのですが、あとはいかに取りこぼしを減らすか(同時に更新を処理する時間を少なくするか)という程度の問題になります。

    内部ロジックが異なるためなのでしょうが、自動検知・更新では取りこぼしがみられるものの、手動Crawlであれば、おそらくほぼ取りこぼしなくDB更新しているように見受けられるので、そのあたりの振る舞いの統一を行っていただくことができればよいのでは、と門外漢ながら存じます。

    いずれにしましても、当面は、ソースディスクに変更を加えた場合は、TBで明示的に手動クロールを実行することで運用することとしますので、実用上はそれほど問題とはなりません。機会をみて、改善のご検討をいただければと思います。(ソフト自体に取りこぼしの可能性があると分かりましたので、ある意味スッキリしましたので、その認識のもとで使用させていただきます。)

    強いていうと、手動クロール機能をバックグラウンドで実行してくれるようなモードがあれば、上記のような運用においては便利ではあります。いまは、手動クロールをかけていると進捗状況のマドが出て、それ以外の操作がでいないので・・・

     

     

    #1296
    Tiki
    キーマスター

    ありがとうございます。

    細かいですが、検討の方針を考える上で大切なので(もしおわかりになれば)確認させてください。

    更新のかかったポータブルディスクを差し込んだ時点で、(そのディスクを管理対象としている場合には)すぐに検知とツリー更新が始まり

    この点は、TuneBrowserの動作は(4.2.4では)問題ないと理解していますが、合っていますでしょうか.

    あるいはポータブルディスクから管理対象としている据え置きディスクにFastCopyやエクスプローラで同期をかけた

    今回、問題となっているのは、この点ですよね.

    手動Crawlであれば、おそらくほぼ取りこぼしなくDB更新しているように見受けられるので、そのあたりの振る舞いの統一を行っていただくことができればよいのでは、と門外漢ながら存じます。

    手動クロール相当の動作をさせるのは簡単なのですが、あるフォルダ以下を総スキャンしますので、時間がかかりますよね。ですので、このやり方は(以前から何度かやりたい衝動には駆られるのですが)ちょっと難しいかなと思います。せっかくご提案いただいたのに、すいません。

    #1297

    更新のかかったポータブルディスクを差し込んだ時点で、(そのディスクを管理対象としている場合には)すぐに検知とツリー更新が始まり
    この点は、TuneBrowserの動作は(4.2.4では)問題ないと理解していますが、合っていますでしょうか.

    →TBでこの使い方を意識してやったことがないので曖昧ですが、おそらく問題ないと思います。やってみる機会があって問題が見受けられた場合は改めて報告致します。

    あるいはポータブルディスクから管理対象としている据え置きディスクにFastCopyやエクスプローラで同期をかけた
    今回、問題となっているのは、この点ですよね.

    →左様です。この場合(で該当フォルダ/ファイル数がそこそこ多い場合)は、ほぼ毎回起こります。

    #1298

    質問

    TuneBrowserでは、管理対象ドライブの把握と識別にあたって

    OSからアサインされているドライブレターのみを用いておられますか?

    それとも、ボリュームラベルやハードウェアIDなども併せてチェックしておられますか?

    もしドライブレターのみであれば、手動でレターを書き換えるなどして比較的容易に前項1つめのテストを行うことができるかと思いますので、お尋ねしました。

    #1299
    Tiki
    キーマスター

    ドライブレターを使用しています。ただしそのドライブがネットワークドライブかどうかはチェックしていますが、今回はあまり関係ありませんね。

    ドライブの認識は、ドライブレターを変更したときに、OSからWM_DEVICECHANGEメッセージが発行されることが条件です。すいませんが、WM_DEVICECHANGE発行の条件はいまこの瞬間は明快ではありません。明日でよろしければ、また再確認します。

     

    #1300

    テストできました

    【テスト内容】

    管理対象としている更新のかかったポータブルディスクを差し込んだ時点で、すぐに検知とツリー更新が始まりDBを正しく更新する(ツリービューに反映する)かどうかのテスト

    【環境】

    昨日使用したWinタブレット(昨日ポータブルHDDでDB更新した状態。その後HDDをには変更が加わっている(追加・タグ編集))

    【結果】

    問題なく自動認識・更新され、DB(ツリー)の数値も正しく思われます。

    【手順】

    タブレットを起動

    HDDを刺さずに、TBを起動 (81/59751)

    HDDを刺しDドライブとしてOSが認識(このタブレットでのTBの管理ディスクレターはD)

    ほどなくしてTBがディスクの挿入を検知しDBの同期を開始、20分ほどかかって正しいと思われる数値がツリービューに表示(81/60012)※手動クロールはかけていない

    以上です

    #1301
    Tiki
    キーマスター

    お忙しいところ、ありがとうございます。

    よかったです。20分ほどかかるのはどうやねんという話はありますが(^^;…。

     

    #1308
    Tiki
    キーマスター

    nikuyamaさん、こんばんわ。

    本日、Crawler関係の処理を見直していて、大量の子項目が更新された場合に更新処理が重くなってしまう問題を発見しました。わたしのところでは、テストを繰り返してももともと処理抜けは認められないので、これが処理抜けに直結しているとはかぎりませんが、処理が多少軽くなったことで、処理抜けの確率は減ったものと思います。

    これの対処を行った版を4.2.4.1345として先ほど公開しましたので、お手数ですが、お時間のあるときにでもお試しいただけると有難いです。

    また、このリリースではこれまで公開していなかったCrawler用のパラメータを設定項目として公開しています(ツリーの「性能の設定」ページのいちばん下にあります)。もし改善していない場合、このパラメータの調整をしてみる手はありますので、またその際にはご連絡させていただければと思います。

    ※ 以前nikuyamaさんが、「PCの性能の問題か」とお尋ねになったときに、わたしは現象を捉え違えていたので「それはない」旨お答えしましたが、「たまに抜ける」という状況だと、その線が濃厚そうです。

    #1316

    残念ながら改善がみられないようです

    1.PC起動

    2.TBを4.2.4.1345へ更新

    3.TB起動

    4.ツリービューの値確認=81/60026

    5.TB起動したまま、FastCopyでポータブルHDから据え置きHD(管理対象)へファイルを追加・更新 → TB反応せず(ログ01)

    6.引き続き、マニュアルクロール実施。ツリービュー更新される(82/60301)(ログ02)

    ※性能関連パラメータは触っておりません

    以上です

     

    https://www.datadeliver.net/receiver/file_box.do?fb=e01dc91dc9c346479c2b546840400ba2&rc=7c48a56c139348bf97548e27ff3cb6a2&lang=ja

    使用PCは、ThinkPad X230であり、そこそこの性能ではあります

    ちなみに、PCの性能について言及したのは、別イシューです(WASAPIイニシャライズ問題の件)

    #1317

    関係ないとは思いますが、

    ポータブルのWestern Digital My Passport 3TBはexFat

    据え置きのBuffalo External HDD 3TBはNTFS

    でフォーマットしています。Allocation Unit Sizeは、それぞれの形式でのフォーマット機能実行時の標準値です。

    ただ、ポータブルHDDだけで完結する場合(そのドライブ内でフォルダ/ファイルの移動)でも、ポータブルから据え置きへFastCopyなどで同期した場合でも起こる現象なので、フォーマット形式は関係ないとは思います。

    ご参考まで。

     

    #1319
    Tiki
    キーマスター

    nikuyamaさん、こんばんわ。

    ご確認と追加の情報ありがとうございます。

    わたしの確認の仕方がまずかったのだと思いますが、すこしまた混乱してきました。ファイル/フォルダが更新されて、その結果が「検出できていない」というとき、以下の2つのパターンがあると思います。

    A. TuneBrowserがまったく反応せず、つまり更新検知の仕掛けそのものが動作していない。
    B. TuneBrowserは反応し、読み込んでいるが、結果として読み込まれているファイルもあるが、欠落しているファイルもある。

    当初、A.だと理解していたのですが、その後の情報から2018-01-07 20:52に、B.のパターンなのだなと認識し、昨日リリースしたバージョンはこのB.の対策を行っています。

    昨日ご連絡いただいた状況には「5.TB起動したまま、FastCopyでポータブルHDから据え置きHD(管理対象)へファイルを追加・更新 → TB反応せず(ログ01)」とのご報告をいただいています。これは、上のパターンでいうところの、A.が発生しているということでしょうか?

    あるいは、A.のこともあれば、B.のこともある、という感じでしょうか? あるいはA.でもB.でもないケースでしょうか?

    A./B. で問題の所在と対策が大きく変わってきますので、お忙しいところ恐れ入りますが、ご確認いただければ幸いです。

    #1320

    A.のこともあれば、B.のこともある だと思います

    当初は、まったくTBが反応してないのかなと思っていましたが

    先日よりログビューのマドを見ることを覚えましたので

    それとツリービューを見比べながら観察していると

    ツリービューがちょこちょこ増加しているようにもみえます

    ただ、ずっとみてるわけではないので、確証はないです

     

    #1321
    Tiki
    キーマスター

    わかりました。ありがとうございます。

    アップしていただいたログには、Crawlerの定時処理とイベント処理が混交して判別できないので、次のリリースで両者のログをふたつに分けて記録するようにします。

    何度もお付き合いいただいて恐縮なのですが、次からは “Crawler(Event)”というタブが登場しますので、そちらをご確認いただければと思います。どうぞよろしくお願いします。

    #1322

    新レビジョンの公開はいつごろになりますか?

    (そのときに、いい具合にテスト対象にできるHDDの状態を準備するため)

    #1323
    Tiki
    キーマスター

    おそれいります。

    改修は終わりましたので、1時間くらいで全ビルドが完了すると思います。

    #1324

    わかりました

    きょうは、仕事の関係でのんで帰るので

    不覚になっていなければ、26時頃試せると思います

    (きょう、いい感じでHDをいじっていたので)

    #1325
    Tiki
    キーマスター

    いやどうか無理をなさらず、明日以降でもお時間のあるときにお願いします。m(__)m

    4.2.4.1345で 終了時に動作を停止する問題が出ていますので本日のリリースは行いますが、4.2.4そのものはそんなに急いでいませんので…。

    #1332

    1.PC起動

    2.TBを4.2.4.1346へ更新

    3.TB起動

    4.ツリービューの値確認=82/60262

    5.TB起動したまま、FastCopyでポータブルHDから据え置きHD(管理対象)へファイルを追加・更新 → 83/60684に

    6.引き続き、マニュアルクロール実施。83/60684のまま

    今回は、ディスク同期中に自動更新されたようです。

    https://www.datadeliver.net/receiver/file_box.do?fb=fc80ea7de3154b3d9e89f561484d65f9&rc=13230c3b8d5443948b60dd07668f1de8&lang=ja

    #1334

    今日、もう一度ためしてみての考察です

     

    1.ポータブル-据え置き 同期前 83/60684

    2.FastCopyで同期

    3.同期終了時 83/60684 しかし、このときLogView(Event)をみていると、すこしづつイベント行が増えていっている。つまりある程度の量が検知対象になるとTBの処理が遅いため反応してなかったように見えているだけではないか(証左として、ゆうべやったときは、2時ころからFastCopyの同期を始めて寝落ちして5時半頃みたら数値が増えていてその後手動クロールしても同じ数値だったから)

    ただし、LogView(Event)が増えていってはいるが、ツリービューの数値は83/60684のままである。TBのツリービューの更新(情報反映)にかなり時間がかかるということ?

    今回FastCopyでの動機が終了してから10分程度経っているがツリービューの情報は更新されていない状態ですが、このまま数時間放置(手動クロールをかけない)してみて改めて報告します。

    ※上記仮説が正しいとするなら、やはりTBの検知更新速度の改善をご検討いただきたいところですねーー。。

    本日のソースHDDの変更概要

    MP3フォルダのフォルダ/ファイルを相当数削除

    flacフォルダにフォルダ/ファイルを相当数新規追加

     

    #1335

    いま、FastCopy同期終了後40分ほどたっていますが

    LogView(Event)が遅々としてTl03: Reading folderをレポートしています

    そして、ツリービューの数値にも変化が出ています(しかし、ツリービューの数値はFB2KのようにほぼHDD更新とリアルタイムに反映されるのに比べて、TBの場合はある程度バッファリングしてからポンと加算・減算して数値更新しているように見えます)

    どうやら、自動検知・更新機能より、手動クロールのほうが速くDB更新処理できる(ツリービュー情報も更新される)ようです。総ナメの手動クロール機能のほうが、部分ナメの検知機能より速いというアイロニー(T_T)かな?

    #1336

    FastCopy同期終了後1時間を過ぎたころ、自動検知・更新の情報ウインドウが表示されて

    ツリービューの数値もズコズコと増えました。LogView(Event)をみると行が増えるのが止まっています

    どうやら、Reading をするのに相当の時間がかかて、それが終わってから更新処理が走っているイメージです。(作者を差置いて素人の想像をしてすみません)

    ここで、ほぼ結論。

    「自動検知・更新がかからない場合がある」というのは私の勘違いでした。すみません!

    もっと、じっくりと物事に対処できる人間になれるよう精進したいと思います。(_ _;)

     

    ※ある程度の数の更新がかかっているときは、自動検知高速モードとして手動クロールと同様の動作をするスイッチがあってもよいかも。今日はMP3ファイルの削除300くらい(かな)、FLACファイルの追加400くらい(かな)だったわけですが、私の環境では、手動クロールであれば5分かからないです。自動検知の20倍以上速いですね・・・(悲報)

    #1341
    Tiki
    キーマスター

    こんばんわ、仔細の情報をありがとうございます。

    「もしかしてそうかな」とは思っていました。

    手動クロールとの速度の差異ですが、例えば以下の構成で10,000個のファイルがFolder001からFolder100に分かれて入っているとして、

    FolderRoot
     |-FolderA
      |-Folder001
      |-Folder002
      |- |
      |-Folder100

    Folder001からFolder100を別のフォルダに移した場合と, FolderAを別のフォルダに移した場合とでは、同じ10,000個のファイルを移動させる場合でも、動作速度はだいぶ異なります。

    手動クロールは後者と同等の動作をします。nikuyamaさんのご提案は、Folder001からFolder100を移動させた場合でも、ある一定数を処理したら、FolderA部分からの全体クロールに切り替えてはどうか、ということですね。そのやり方はこれまで何度か考えはしたのですが、Folder100では止まらず、Folder999まであったら逆に必要のないフォルダもクロールすることになってしまいます。

    まあそれはともかく、結論的には現状では遅すぎて使い物にならないという話ですよね。

    以前、まだわたしのノウハウもあまりなかったころ、多数のファイル形式をサポートするなかで、よく想定外の理由でエラーを起こしていました。それを改善するために、大量の情報を蓄積しながらクロールしているのですが、現在もその「大量の情報」は残したままです。現在では、ファイルが壊れているようなケースでないかぎり、原因不明のエラーということは少なくなってきたので(なくなったわけではないです)、もうすこしそのあたりの情報を減らしていくべきなのかもしれません。

    手許の検証用の環境では、10,000ファイルを新規登録するのに、だいたい120秒くらいかかっています(ディスクキャッシュが効いた環境であり、実際にご利用いただく環境とは異なります)。すると、1ファイル12msくらいですので、あちらこちらの処理で1msずつ削って、6msになれば1分、3msになれば30秒、というところを詰めていくしかなさそうです。あるいは、わたしの知らないまったく違う次元のやり方があるのか…。

    それから、GUIの更新が遅い件ですが、「ファイルの取りこぼしがある」というご指摘への対策でしたので、今回のリリースではGUIの更新は大幅に遅くしてあります(3,000個のファイルの更新を確認したらGUIを更新する、としたと思います)。その結果が現れているものと思います。これは緩和するようにします。

    #1343

    仕様のご説明をありがとうございました。

    わたしのようなソフトお宅(ただし、開発はできないで使うだけ)は、内部でどのような振る舞いをしているかがわかれば、それでスッキリして現状に合わせますので、本件については当分のあいだ手動クロールすることで問題ありません。

    たしかに、TuneBrowserは、タグ情報などFB2Kに比べても豊富にサポートされていて、その他情報も同ソフトに比べて相当にリッチなので、速度とのトレードオフになることについては、悩み多いところでしょうね。

    ファイル読み込みと同様に、TBの起動時や終了時にも、それなりの時間がかかることから、いろいろ豊富な情報を読み書きしてるんだろうな~と微笑ましく動作を見守っておりましたので、除々にではあれパフォーマンス改善が進まれることを期待します。

    それにしても、LogView(Event)表示機能を作成していただいたお陰で、解決が早まり助かりました。ありがとうございました。

    #1345
    Tiki
    キーマスター

    薄々わかっていたことながら、その後分析してみても、12msの処理のうち明確に1ms以上かかっている処理などはなく、1ms未満の処理を数カ所改善して、合計で2ms程度短縮できたという感じです(それでもわたしとしては、実際に改善点を見つけられたのですから、達成感は感じられる成果ではあります)。(^^;

    歳のせいか、とくに夜はどうしてもアプローチが局所的になりがちなのですが、今朝出勤のために歩いているときに、昨晩から見れば「まったく違う次元のやり方」をひとつ思いつきました。複数スレッドで並列処理をさせてみようと思います。

    マルチコアの時代、そんなことは常套手段であって、実際にTuneBrowserもコンバータなど多くの箇所で分散処理を行っているのですが、個人的に、ひとつのデバイス(この場合はディスク)のI/Oに対して並列処理で攻め立てるのはあまり趣味ではなく、クローラに適用することはこれまで真剣には考えてきませんでした。クロールしている間はPCの負荷が不快な状態になってしまうことも考えられます。実際、その処理をしているRAMDecodeの並列読み込みも、あまり性能改善には至れていません(RAMDecodeはユーザ操作をトリガにしてバースト的に読み込むので、PCの状態には気を遣っていません)。

    ただ、12msの内訳を調べていると、そこそこCPUの処理で時間がかかっているところもありそうなので、意味がないこともなさそうだと思い至りました。

    この手の処理は不具合の温床になりがちですので、すこし時間がかかるかもしれませんが、検討してみようと思います。結果として、10,000ファイル120秒が110秒になった、という話で終わるかもしれませんが。

    まだほかに「まったく違う次元のやり方」があるような気はするのですが、本当に無念なことに、思いつきません。

    こうしたことを再検討する機会になったことは、感謝しています。(^^) 本件、返信無用です。

    #1346

    なるほど~ CPUが結構喰っているのですか、私などは昔のコンピュータのイメージを引きずっているので、I/O速度の限界に塞がれているのかな、、などと思っていました。

    とまれ、違う次元のやり方が天啓のように現れるとよいですね!

    もしかすると、断捨離だったりして。。。

    #1529
    Tiki
    キーマスター

    nikuyamaさん、こんにちわ。

    別のトピックの内容から、4.3.0の先行版をご利用いただいていると拝察します。4.3.0はクローラが並列動作するようになっていますが、本件の状況はいかがでしょうか? 後学のためにも、改善があったかどうか、教えていただけると有り難いです。

    よろしくお願いします。

    #1539

    4.3.0で、なんとなくこれまでよりは自動クロールの反応が速くなったかなぁという気はしていますが、確証はありません。

    具体的にどのようなケース(自動クロールの始まる(感知されるまでの)時間、自動クロールが完了する時間、手動クロールも関係あり? など)に気をつけて観察しておけばよいか仰っておいていただけると、そのようにし、報告致します。

    関連質問で恐縮ですが、

    1.手動クロールの実行速度も改善されていますか?

    2.手動クロールをバックグランドで実行するオプションのようなものはできないでしょうか(手動クロール中も他の操作をしたい・・・) ※原理的に無理な話かもしれませんが。。。

    よろしくお願いします

    #1568
    Tiki
    キーマスター

    こんにちわ。

    4.3.0で、定期クロール、イベントクロールは手動クロールとほぼおなじ動作になっています (ログの出力先などは異なりますが)。手動クロールの動作速度はあまり変わっていません。ちまちま改善はしているので、100msの処理が99msになった、というような部位はあるかもしれません(^^;。

    手動クロールのほうが、ユーザの意思で対象フォルダを指定できますので、その意味では絶対に効率は良いです。

    手動クロールの非同期で実行するのは、原理的には可能なのですが、競合の設計をやり直さないといけないので、道は険しいです。

    よろしくお願いします。

    #1591

    どうも、いまいちのようです。

    前にクロールしたときから、同じHDでクロール対象のフォルダ名を変更していると、ツリービュー(つまりDB)にある以前の登録が残っているように思われます。

    新しいディレクトリ構造のエントリーは新しくツリービューに反映されているものの、古いエントリーも残っているようです。ただし、過去のものがきれいに全部残っているわけでもなくて、新しい構造にともなって消されたものもあるように見えます(対象ファイル数が多いので、詳しくすべて調査することはできないので印象です)

    よろしくお願いします

    #1603
    Tiki
    キーマスター

    ありがとうございます。

    クローラの機能として退化している、ということですね…。無念ですが、もう一度見直してみます。

    #1616
    Tiki
    キーマスター

    こんにちわ。

    先ほど、クローラの取りこぼし対策を強化した先行版4.3.0.1351をリリースしました。お時間のあるときにでもお試しいただけると有難いです。

    よろしくお願いします。

    #1628

    あきません

    寝といてください

    #1635
    Tiki
    キーマスター

    ご心配おかけしてすいませんでした。すでに復活しております。

    発熱で寝ている間、何度もクローラの夢を見ました(^o^;。TuneBrowserが使い物になるかどうかのところにいると理解していますので、何とかこれで実用になるとよいのですが。

    #1640

    祝復活🎌

    明日、試して報告致します。

    #1641
    Tiki
    キーマスター

    ありがとうございます。

    ご無理をなさらず、お時間のあるときにお願い致します。

    #1659

    残念ながら状況改善せずです。
    詳しく申すと、こういう手順です。

    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ディレクトリ名のものは新規のものとしてこれはこれで新規登録している。

    よろしくおねがいします。

    #1663
    Tiki
    キーマスター

    こんにちわ。確認いただいてありがとうございます。

    おそらく、ディレクトリ名の変更は\flacから\FLACへと大小文字の変更であり、TBはUpper・Lowerの違いを区別していないからではないかと推察される。

    えっと… フォルダ名の大文字小文字の変更で多重登録が発生する、というのは今回新しい話ですよね? 1月上旬ごろに問題にされていた、イベントクロールの動作速度のほうはいかがでしょうか?

     

    それで、フォルダやファイル名の大文字小文字の区別の件なのですが、この現象は以下の状態のため発生します。

    • OS(Windows)は大文字小文字を区別していない.
    • TuneBrowserは大文字小文字を区別している.

    OSのほうの仕様はよくご存知だと思いますが、TuneBrowserの仕様のほうは、これは動作中のさまざまな文字列比較時の効率の問題で、このようにしています。OSとTuneBrowserでここが合っていないというのは、もちろんあまりよろしくはないのですが、実際にはユーザがパス名を手入力するケースはほとんどなく、発生してもデータベースのエントリを消してもらえばいいだけの話ですので、開発着手時から8年間、この効率優先のままです。

    これまであまりこの辺の仕様については、説明できていなかったかもしれないですね。質問されたこともなかったですが…。

    今回やられたようなケースへの対策は、また別の課題として検討していきたいと思います。まずは基本的なクローラの動作を確定したいと思っていますので、1月ごろお話しになっていた観点で見ていただけると助かります。

    いろいろとお手数をおかけします。どうぞよろしくお願いします。

    #1664

    失礼しました

    前記載の

    「どうも、いまいちのようです。

    前にクロールしたときから、同じHDでクロール対象のフォルダ名を変更していると、ツリービュー(つまりDB)にある以前の登録が残っているように思われます。

    新しいディレクトリ構造のエントリーは新しくツリービューに反映されているものの、古いエントリーも残っているようです。ただし、過去のものがきれいに全部残っているわけでもなくて、新しい構造にともなって消されたものもあるように見えます(対象ファイル数が多いので、詳しくすべて調査することはできないので印象です)」

    の繋がりとして本日記載しました

    速度については・・・

    目視での感覚でしか申しようがないのですが、
    従前より変更検知の速度は上がっているようには感じます
    (しかしながら、FB2Kのようなスルスル感までは程遠い印象です、ただしこれは言っても詮無い比較なので今後申しますまい)

    それと、これも印象ですが
    HDがPCに接続ずみの状態でかつTBが起動している(つまりHDをモニタリングしている)状態でHDに変更を加えたときの検知反応速度はこれまでより大分と速くなった「気がします」が、別PCで変更ずみのHDをPCに接続してTBを起動したときの検知速度はだいぶ以前の版よりは早くなったもののもう少しなんとかなならんかなとの印象です。

    これも比較してもしょうがないのですが、FB2Kではいろいろなディレクトリに変更がかかっていてもつながってスルスルDB更新してくれるのですが、TBの場合はあるディレクトリについて更新したらちょっと休んで別のディレクトリについて更新して、また休んでみたいな動きをします
    まぁ、忘れておいて他の作業をしていればいいのですが、気になりだすと「もう更新終わったかいな、いつ終わるんかいな」ときになってしまうので・・・
    更新終了する前にTBを終了するのもアレな気がするので、LogViewでクロール終了してることになっているかを確認したりして、僕ってけなげなユーザーと思ったりして。

    一定量の変更に対するDB更新のトータル速度については、速くなったかどうかはよくわからないというのが正直なところです。ファイル更新量によって都度違ってくるから。

    ある一定の更新に対してDBを新規作成にして、旧版と新版で速度比較してみればいいのですが、そこまではちとめんどくさい。。

    よろしくおねがいします

    #1665

    そういう意味では、こちらから「印象」でレポートされても開発の効率が悪いでしょうから、
    なにかテストシークエンスと計測ツール(あるいは手順)みたいなものをご提供いただければ
    貴殿の参考により資するものになるかと思います

    #1670
    Tiki
    キーマスター

    ありがとうございます。

    別PCで変更ずみのHDをPCに接続してTBを起動したときの検知速度

    問題なのは、ドライブをマウントしたときの動作速度なのですね。こちらのほうは、定期クロールを再起動して、そのままそれに任せた状態になっていました。イベントクロールで処理するように変えてみます。

    TBの場合はあるディレクトリについて更新したらちょっと休んで別のディレクトリについて更新して、また休んでみたいな動きをします

    まだ本当にそのような動作をしていますでしょうか? この点は、このひと月ほどでだいぶ改善したと思うのですが…。

     

    クロールの動作速度は、HDD/SSD/NASといったデバイスの種類や、SATA接続/USB2.0・3.0/100Mbps・1Gbpsかといった接続形態、さらにデバイスとOSのキャッシュの状態によって大きく変わります。そのため、nikuyamaさんご所望の評価基準の設定というのは残念ながら困難です。

    大切なのは、nikuyamaさんが、ここで「もう少しなんとかなならんかなとの印象です」と言われていることだと思います。TuneBrowserのクロール処理が使い物にならないという状態で、終わらせたくはありません(くじけそうですが)。

    #1677

    >まだ本当にそのような動作をしていますでしょうか?

    LogView窓と、クロール状態表示窓(半透明のやつ)をチラチラ見ている限り

    そのように思われます

    #1695

    もしかすると

    1.実際は、ディレクトリをまたいで、途切れずにクロール処理しているものの、クロール進捗情報窓(半透明のやつ)が一定時間で消えて何かのタイミングでまた表示再開されるので、処理が途切れているように見えているだけでしょうか。(以前に、進捗窓は放っておくと消えるというお話があったように思いましたので)

    だとすると、それを検証するために

    2.TBの1起動単位中に処理された(ファイル単位の)全クロールログを取得する方法はありますか?それを見れば、クロール処理が途切れたか途切れていないかを時間軸で確認できるから。

    よろしくお願いします

    #1698
    Tiki
    キーマスター

    こんばんわ。

    途切れずにクロール処理しているものの、クロール進捗情報窓(半透明のやつ)が一定時間で消えて何かのタイミングでまた表示再開されるので、処理が途切れているように見えているだけでしょうか。

    その可能性はあると思います。

    ただ、今回はクロールの並列化を行ったということなので、いっぽうでGUI側の更新速度にも課題は残っているのだと思います。GUI側のキューがいっぱいになると、Crawlerは安全のためGUI更新を待つようになっており、それが「待ち」に見えている(というか「待ち」そのものですが)可能性も高いです。

    ということで、いまGUI側の更新性能を上げられないか、あれこれやっています。ここは並列化のような力技はできないので、現状動作の分析とそれに対する知恵がどれだけ出せるかということなのですが、基本そんなに頭が良くないので試行錯誤です。

    #1699

    はい、GUI(ツリー表示部分)への反映がもぅちと速くなると使いやすいです

    #1744
    Tiki
    キーマスター

    先ほど、高速化した先行版をアップしました。

    GUI更新部分は以前とやり方を変えたので、以前とはちがう次元の動作になっていますが、そのぶん不具合がある可能性もあります…。

    それと、大文字小文字問題も対処してあります。

    どうぞよろしくお願いします。

    #1759

    自動クロールにて、

    ①古いディレクトリ名時代の登録について、新版でも消されることはありませんでした(前のレポート時と同様の状態)

    ②また、ディレクトリ名は変更されていないが、タグ編集でジャンルが変更されているものについてもそれが反映されていません(前のレポート時と同様の状態)

    ①について、新ディレクトリ名に基づく新DB登録はされています

    ②について、新タグ情報(ジャンル名)に基づく新DB登録はされていません

    もしかすると、私がそういう仕様であることを勘違いして、おかしいおかしいと騒いでいるだけでしょうか?

    新規エントリーについてのDB登録やツリーへの反映は速くなったように思います(ただし計測・比較をしたわけではなく、あくまで印象であります)

     

    #1760
    Tiki
    キーマスター

    ありがとうございます。

    検出されない問題ですが、前回の例でご提示いただいたフォルダ構成は変わりませんか?

    e:\files\flac\xxxxxxxx
    e:\files\MP3\xxxxxxxx

    このときに、管理フォルダとして登録されているのは、”e:\files” ですか、それとも “e:\files\flac” ですか。

    あと、ジャンルのほうですが、楽曲形式は何でしょうか(MP3, FLAC等々…)? ジャンルを編集したのはTuneBrowserですか、それとも別のソフトですか? 別のソフトの場合、そのソフトはジャンル番号かジャンル文字列のどちらを書き込んでいるかおわかりになりますか?(TuneBrowserはジャンル番号は認識しません)

    別のトピックでもご報告されているような、認識されていなさそうなファイルがある場合、そのファイル/フォルダをTuneBrowserにExplorerからドロップすると、TuneBrowserはそのファイル群の情報を読み込んで更新します。そうした操作を行ってみていただけませんか。それでも古い情報のままでしょうか。

    #1761

    動作速度については、前掲のとおりです

    >新規エントリーについての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:
    #1763
    Tiki
    キーマスター

    あー、管理フォルダそのものの名前の大文字・小文字を変更されたのですね。わかりました。その観点は抜けていたかもしれません。

    ジャンルのほうは、ひょっとしたらその影響かもしれません。

    #1765

    ※別トピックと関連する内容ですが、こちらのトピックに書きます

     

    昨日とは別環境の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登録されていない(ツリーに現れない))アルバム/楽曲があったかどうかは、本日の観察ではわかりませんでした。

    宜しくお願いします

    #1766
    Tiki
    キーマスター

    お忙しいところご確認ありがとうございました。

    3分くらいの「ひと休み」は、私が考えていたものとはちがっていました。TuneBrowserを起動して、ドライブをマウントしたときには、以下の順番でクロール処理が走ります。

    1. ドライブマウントに対応したイベントクロール
    2. 起動後のクイッククロール
    3. 定時のフルクロール

    これら3つは連続して動作するわけではなく、それぞれにタイミングに基いて動作します。おそらく1.2.3のどれかが走って、その後次の1.2.3のどれかが走ったのを目撃されたのだと思います。

    本日ご確認いただいた状況は、問題なさそうと受け取りました。

    その前にいただいた、

    1. 管理フォルダの大文字小文字が変わった場合の処理
    2. ジャンルの検出漏れ

    このふたつを順番に片付けましょう。2.は1.の余波の可能性もあります。

    1.のほうは、思いがけず大手術になっています。昨晩からずっと改修をつづけているのですが、なかなか手ごわいです。

    #1767

    ありがとうございます、ご無理のないようにお願いします

     

    ただ1点気になるのは、前回同期時からHDに変更がないのに、本日PCに接続してTB(新版)を起動したところ、進捗マドに

    Deleted, New File 云々の更新メッセージが出たことです

    これは、前回に漏らしていたということなのかな?と。

    よろしくお願いします

    #1768
    Tiki
    キーマスター

    4.3.0がずっと先行版のままですので、ちょっと焦ってます(^^;。

    これ用に、壊れてもよいポータブルHDDも調達してきました。

    Deleted, New File 云々の更新メッセージが出たことです

    大文字小文字の区別が効いたとか、そういうことなのかなとも思いました。

    #1769

    かもしれませぬ

    今やっていただいている対処によって派生的にイロイロ治るような気もしております

    よろしくお願いします

    #1774

    改修でご苦労をおかけしているところ、もしかするとムカつかせてしまうかもしれない事象について報告致します。。

    昨夜遅くに自宅の別のパソコンでTBをいじっていたところ、自動クロールで過去(小文字→大文字ディレクトリ名変更前、ジャンルタグ変更前)に登録されたDB登録情報が削除されない件につき、次のような条件で起こるのではないかと推察できる事象が見られました。

    【古い登録が残る場合の手順】
    1.TB4.3.0.1352以前の版で、過去のHDの状態(状態1)でDB同期
    2.TBを4.3.0.1352版にして、更新されたHDの状態(状態2)で自動クロール→古いDB情報が一部残る
    3.TBを4.3.0.1353版にして、さらに更新されたHDの状態(状態3)で自動クロール→古いDB情報が一部残ったままとなる

    【古い登録が残らない場合の手順】
    1.TB4.3.0.1352以前の版で、過去のHDの状態(状態1)でDB同期
    2.TBを4.3.0.1353版にして、さらに更新されたHDの状態(状態3)で自動クロール→古いDB情報は残らず新しいディレクトリ名/タグ情報に基づいてDB更新されたようにみえる
    ———————————————————–
    参考)

    (状態1のHD)
    ディレクトリ名 \Files\MP3\、\Files\flac\
    ジャンルタグ  (MP3)Jazz 、(FLAC)Soul など

    (状態2、3のHD)
    ディレクトリ名 \Files\MP3\、\Files\FLAC\
    ジャンルタグ  Jazz、Soul など
    ———————————————————–

    推察するところ、ディレクトリ名対応されていない先行版を途中

    に挟むと、DBの登録状態がおかしくなってしまうが、ディレクトリ名対応した先行版に直接UpgradeするとDBの登録状態は正しいものとなる、という動きのようです。よって、1353版で対処していただいたディレクトリ名変更対応は奏功しているのではないか。いずれにしても1352も先行版(テンタティブ)であるので、この問題について追求していただく必要性は低まったのではないか。(一般的には、正式版から正式版へのUpgradeで問題がでなければよいので)

    上記の現象は、ある1台のPC環境で検証しただけのものであり、別のPCでも同じようになるかどうかは確証がありませんし、本当に全ファイルを対象にDB更新されたかどうかまでも確認することができません(6万曲以上あるし、あちこちのファイルについて情報更新しているので確認は事実上不可能)が、ご参考までお伝えしておきます。

    いずれにしても、もっと問題点を追求なさって品質向上に努められるかどうかは、開発者さんのご判断ですので、上記は一現象レポートということで扱っていただければと存じます。

    よろしくお願いします。

    #1777
    Tiki
    キーマスター

    仔細のご報告ありがとうございます。

    今回、TuneBrowserのパス名の大文字小文字の区別の仕方が一部で中途半端だったという点に問題があったと思っています。大文字小文字だけが異なるファイルが登録された場合、二重に登録されて、本来のファイル名とは異なったほうのエントリが置き去りになることがあります。そしてnikuyamaの環境ではそれが「タグ変更が反映されない」エントリとして見えていた可能性があります。余波ではないかというのはそういう意味です。

    今回のご報告も含めて、まずは大文字小文字の区別を厳密に取り扱えるようにして、それで様子を見ていただくということでお願いできればと考えています。

    いろいろお手数をおかけしますが、どうぞよろしくお願いします。

     

    #1784

    ありがとうございます

    次の先行版(あるいは正式版)のビルド提供の日程目処がわかればご教示願えれば幸いです。そのタイミングに、HD更新のDB反映のタイミングを合わせるようにすれば検証に資することができるので。。

    よろしくお願いします。

    #1785
    Tiki
    キーマスター

    お手数をおかけします。

    今晩を予定しています。

    #1790
    Tiki
    キーマスター

    遅くなりましたが、先ほど先行版4.3.0.1354を公開しました。

    お時間のあるときに、見ていただけると助かります。どうぞよろしくお願いします。

    #1791

    前記の

    【古い登録が残る場合の手順】
    1.TB4.3.0.1352以前の版で、過去のHDの状態(状態1)でDB同期
    2.TBを4.3.0.1352版にして、更新されたHDの状態(状態2)で自動クロール→古いDB情報が一部残る
    3.TBを4.3.0.1353版にして、さらに更新されたHDの状態(状態3)で自動クロール→古いDB情報が一部残ったままとなる

    の環境に対して、1354を適用し、30ファイル程度の更新のかかったHDを装着し自動クロールに任せたところ、古い登録が削除され、本日の30更新についても新規登録されました。

    クロール速度、ツリー表示への反映速度については、不満足を感じない程度である(ただし主観)と思いました。

    しばらくHDの更新にともなって、観察してまいります。

    ありがとうございました。

    #1792
    Tiki
    キーマスター

    あー、よかったです。

    速報、どうもありがとうございました。感謝します。

    #1794

    次の手順で、ツリービューに反映されない事象が発見されました。

    1.DB同期済みのHDを接続しWindowsに認識されていることを確認後TB(.1354ビルド)を起動

    2.アーティスト別に管理しているサブフォルダに新アルバムを追加→自動クロールされたと思ったもののツリービューに反映されない

    3.おかしいと思って、そのアーティストのサブフォルダを対象に手動(強制)クロールしたが、ツリービューに反映されない

    4.TBの右下のペインにはそのアーティストのサブフォルダに格納されているアルバムがすべて(5つ)表示されているが、ツリービューには表示されていない

    5.右下のペインのアルバム表示で、左の2つはアルバム名の上にアーティスト名が表示されていない(その2つについてツリービューに表示されていない)。その2つのタグのつき方は、添付2つ目のとおり。

    アーティスト名:Eli DegibriかEli Degibri Trio

    アルバムアーティスト名:2つともEli Degibri

    音声形式:FLAC

    TBのバグでしょうか、タグの付け方がまずいのでしょうか?

    たまたまこのアーティストで気が付きましたが、他のアーティストについても同様のことが生じているような気がします。

    ※新トピックスにしたほうがよければ、貴殿にて移動をお願いいたします。

    よろしくお願いします

    #1796

    続報します

    さきほどのツリーにいないといった2ツのアルバムについて、そのカテゴリの一番上に「名無し」で登録されていました

    これらのタグ付けをいろいろやってみて正しくアルバムアーティスト名のところに収まるか試してみてもよいのですが、まずはご意見(とご指示)をいただくまで、触らずにおいておきます。

    よろしくお願いします。

     

    Attachments:
    #1798
    Tiki
    キーマスター

    こんばんわ。

    続報のほうのスクリーンショットのステータスバー部分の表示から察するに、ALBUM ARTISTまたはALBUMARTISTタグのどちらかにスペースが入っていて、それが表示されているのではないかと思います。

    ご確認いただけないでしょうか?

    P.S. 最初のポストの添付ファイルには、バージョン情報ダイアログにnikuyamaさんの本名と思しき情報が表示されていたので、私のほうで削除しました。

    #1801

    調べてみましたが、スペースがはいっている、何も入ってない、先頭にスペースが入っている などの状況はありませんでした

    参考として、TAGSCANNER(https://www.xdlab.ru/en/)というソフトでタグをダンプしたものをお送りします。黄色で塗った部分が、TBで名無しに分類されたものです。

    ※解決するまで、対象アーティストのタグメンテは止めておきます

    ※必要であればFLACファイルそのものの参考提供も可能です

    よろしくお願いします

    Attachments:
    #1803

    別PCでは、正しく表示されていることがわかりました。

    クロール時になんらかの条件があると起こるのかもしれません。

    添付は、別PCのもの。

    よろしくお願いします

    Attachments:
    #1805

    現象の出ていたPCでTBを起動したまま一晩中(10時間程度)放置していましたが、ツリーに名無し登録があるところはそのままでした(おそらくその間に自動クロールが走ったものと思いますが)。

    そこで、いったんTBを終了して、すぐにTBを再起動(PCは再起動していない)してみると、名無し登録がなくなり、正しくEli Degibriというアーティストの中に5ツのアルバムが表示されていました。

    ツリー部の表示更新処理に課題があるのでしょうか?

    よろしくお願いします。

    #1806
    Tiki
    キーマスター

    続報ありがとうございます。

    TAGSCANNERの出力は、おそらくすべてのタグを表示していないのではないでしょうか。”albumartist” のカラムが “ALBUMARTIST” を示しているのだとしたら、これとは別に “ALBUM ARTIST” というタグが混入していて、そこにスペースあるいはゴミデータが含まれているのではないかと推察しています。

    「TuneBrowserを再起動したら正しく表示された」との情報で理解できたのですが、TuneBrowserはファイルからタグを読み取ったあと、データベースに書くときにゴミデータを除去して書き込みます。ただしその後画面に出すときには、ファイルから読んだデータをそのまま利用しているため、ゴミデータを含んだ状態で表示されてしまいます。次に再起動したときには、こんどはデータベースから読み込むため、ゴミデータが除去されていて、正しく表示されたのだろうと思います。

    これは、次のリリースのときに、ファイルから読み込んだデータそのものをスクリーニングするように動作を変更したいと思います。ただ、いまちょっと4.3.0 UWP版の件でマイクロソフトと調整中で、4.3.0を更新できるか、4.3.1になるかはすいませんが微妙です。

    確認してみたいので、お手数ですが、ファイルを送っていただけますか。この後、ご登録のメールアドレスに送信方法をお送りいたします。

    #1808

    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にしたもので、カラムの位置とか不要カラムの削除とかしていますので、上記の指定の順序どおりにはなっていません。エクセルの1ぎょうめは、私がつけたもので、albumartistと全小文字・スペースなしで書いたのは、私がそうかいただけです。ただ、上記指定のように”%albumartist%”と指定しているので、それに合致するタグ内容がダンプされたのだと思います。試しに、”%album artist%”という指定も加えてダンプしてみましたが、これは出てきませんでした。

    さきほどご指定のフォームから送信しましたが、

    完了画面でFile is not selectedと表示されています

    サーバ内には、到着してますでしょうか?

    #1809

    昨日申した、「別PCでは正しく5ツ格納されていた」件ですが

    このPCではだいぶ前のTB版で1ヶ月くらい前のHDの状態でDB同期したものに対して

    昨夜TBを最新ビルドにして自動クロールしたら対象アーティストの箇所に5ツのアルバムが入っていたものです。ですので、5ツのアルバムのうち2ツにタグの不整合・ゴミなどがあったのであれば、この同期でも現象が出たPCと同じようなツリー表示になるのではないかと思います・・・

    さきほど、もう一度フォームから再送信してみましたが、またも同じくFile is not selectedが出ました。

    21.6GBです。大きすぎますか?

    もし大きすぎるなら、わけて送りますので1送信時の最大許容サイズをご教示ください。

    よろしくお願いします

    #1810
    Tiki
    キーマスター

    到着していませんでした。

    手づくりスクリプトですので、なにか不備があるかもしれないですが、ほかの方のファイルは到着していますので、すいませんがファイル名を変えるなどして、試してみていただけないでしょうか。

    #1811
    Tiki
    キーマスター

    あ、大きすぎるかもしれません。

    ファイル一個だけで結構ですので、お願いします。

    #1812

    265MBでも同じエラーになるので、データ便で送りました。

    DLのURLはメールにてお送りします。

    データ便したファイルは、1ツのZIPに各5アルバムの1曲めだけをいれています。

    よろしくお願いします

    #1813
    Tiki
    キーマスター

    ですので、5ツのアルバムのうち2ツにタグの不整合・ゴミなどがあったのであれば、この同期でも現象が出たPCと同じようなツリー表示になるのではないかと思います・・・

    なるほど、おっしゃることがわかりました。

    ファイル受領しました。追って調べてみます。

    #1814

    現象が出たPCでは、そのとき、右下のペインのアルバム名の上にピンク色のアーティスト名が表示されていないものがあると申しました。(その表示されていないものが、名無しに分類されたもの)

    で、別PCでみると、5ツのアルバムすべてについて、右下ペインでアルバム名の上にピンク色のアーティスト名が表示されていました

    でで、現象が出たPCでTB再起動によって5ツ正しく分類された状態で右下ペインを見ると、5ツともアルバム名の上にピンク色のアーティスト名が表示されています

    参考になるかどうかわかりませんが、気づいたことをお伝えしておきます

    よろしくお願いします

    #1815
    Tiki
    キーマスター

    ありがとうございます。

    ご指摘の通りで、ですからツリー単体の問題ではなく、アーティストの認識の問題だと捉えました。

    TuneBrowserは、アーティスト名は

    ALBUM ARTIST; ALBUMARTIST; ARTIST

    の順で検索し、最初に値の入っていたタグを使用します。そのため、ALBUMARTISTに適切な値が入っていたとしても、ALBUM ARTISTにゴミデータが入っていると、ゴミデータが表示されます。

    今回はそのケースにぴたりとハマりますので、このケースだろうと考えたのですが、お送りいただいたデータは全アルバムともアーティスト名は問題なく表示されました。

    とすると? というのはまた今後です。

    ちなみに、nikuyamaさんのところではもう二度と再現しないですよね?

    #1816

    分類おたくですみません

    よろしくお願いします

    #1817

    >ちなみに、nikuyamaさんのところではもう二度と再現しないですよね?

    いまのところ再現しておりません

     

    よろしくお願いします

    #1819

    これは、ダムユーザの根拠なき仮説ですが、5ツのうち2ツ名無し現象が出たPCは、いちばん頻繁にTBの版(マイナーレビジョン)更新をしクロールに係る検証をしている機械ですので、DBに一部コラプションがあったのかもしれないという視点もあるかと。TBのファイルからのタグ情報読み出し処理に問題ありの視点でなく、DBがくちゃけてたのではとの視点。

    寝言です。

    よろしくお願いします。

100件の投稿を表示中 - 1 - 100件目 (全109件中)
  • このトピックに返信するにはログインが必要です。