- このトピックには108件の返信、2人の参加者があり、最後ににより6年、 6ヶ月前に更新されました。
-
投稿
-
>複数の管理フォルダをまたがった更新(フォルダやファイル移動など)が発生した場合に、どちらかの変更をとりこぼすことがある問題を改善しました.
上記対応項目とは違う想定用法かもしれませんが、
次のような場合に、DBが自動更新されません。
自動検出更新、Update Database ともに期待動作しない（追加したアルバムがツリーに反映されない）
Manual Crawlを明示的にかけると反映される
１．4.2.4を立ち上げている状態で
２．\AAA\というフォルダに \AAA\111 と \AAA\222 を追加
（111と222はフォルダ（アルバム）で、これらの中にはFLACファイルが入っている）
・「複数の管理フォルダをまたがった更新」ではありません
・￥AAAは管理対象として設定されているフォルダです
この減少は、4.2.3からあるもので、うまくレポートの意図が伝わっていなかったかもしれません。
こんばんわ、Tikiです。
すいません、よく状況が掴めていません。
２．\AAA\というフォルダに \AAA\111 と \AAA\222 を追加
このケースで問題が出ると言われているということは、111 ひとつだけを追加した場合には問題がなくて、111と222のふたつのフォルダを追加した場合に「自動検出更新、Update Database ともに期待動作しない」ということでしょうか?
またその場合、111も222も両方登録されないのでしょうか?
ひとつだと検出されるのでしょうか?
ありがとうございます。
「さきほどのPCとは別の環境」では、問題なく動作しているという理解でよろしいでしょうか?
問題の起きている方のPCでは、(複数以前に)ひとつだけフォルダを追加したときにそもそも正しく動作するかどうか、というのは、わからない感じでしょうか?
何度も同じ確認で恐縮です。
わかりました。ありがとうございます。
すこし上にも書きましたが、問題のPCでは、複数フォルダの問題というよりは、そもそも更新の自動検知がはたらいていないような気がします。
その原因は、すぐに思い当たるのは、当該のドライブがNASになっていて、NASで自動検知を行う設定を有効にしていない(既定では無効です)のではないかな、という点です。
またもし状況がわかれば、ご連絡をお願いします。m(__)m
仔細の情報をありがとうございます。お手数をおかけしています。
伺った状況から、FastCopy340を使用したときの問題かなと思い、ダウンロードして試してみましたが、やはり正常に検知しました。
つまり、TBが管理しているドライブ／フォルダ内で直接ファイル操作するのではなく、別のドライブで行ったファイル編集等の結果をエクスプローラやFastCopyなどで管理先ドライブ／フォルダへコピーしたような場合はTBがこれを検知していないように見受けられます
これは、Crawlerの基本職務のひとつですので、機能としてこのケースが検知できないということはないです。でもnikuyamaさんの環境では実際に検知できておらず、また、問題が発生しないPCもあることから、なにか環境の要因なのだろうと思います。
あまりお手数をおかけするのは心苦しいのですが、問題の出ているPCで、外付けHDDではなく内蔵のHDDでは機能が動作するかどうか、お時間のあるときに試してみていただけないでしょうか?
すこしでも要因の切り分けができれば、と期待しています。
お時間のあるときで結構です。どうぞよろしくお願いします。
お忙しいところありがとうございます。
状況から、HドライブにUSBで接続されている “Buffalo External HDD 3TB” についてのみ、ファイル更新が自動検出されないと理解しましたが、合っていますでしょうか?
(わたしも普段使いでは、USB接続の3TBの外付けHDDを使用しています。もちろんこの環境でも更新は検出されています。ですので、一概に外付けだからダメということはありません)
先にアップいただいたログには、Gドライブをマウントした形跡はありましたが、Hドライブのそれはありませんでした。これは、言われているように、Hドライブは着脱せずマウントしたままご利用なのですよね。
念のための確認なのですが、このHドライブに対する外部ソフトからの更新は、TuneBrowserはまったく反応できていないのですよね?
それと、以前お伝えしたLog Viewで、Crawlerタブの内容の最初の10行程度を貼り付けていただけないでしょうか? ファイル更新などは必要なく、起動後しばらく(1分程度)した後のもので構いません。
お手数をおかけします。よろしくお願いします。
なるほど、「検出できないときもある」状況ですか…。
ログをお願いしたのは、TuneBrowserは起動後しばらくすると、Quick Crawlを開始します。そのときに、何らかの理由でエラーが検出されていないかと考えた故です。
ちょっとむずかしいのですが、「TB起動時に自動クロールがかかった直後」ということになります(^^;。ただ、「検出できるとき/できないときがある」のであれば、このときにはエラーは出ていない可能性が高くなってきたので、もし難しいようでしたら無理なさらないようにお願いします。
nikuyamaさん、こんばんわ。ありがとうございます。
アップしていただいたログを拝見していて、すこし状況の理解が間違っていたことに気が付きました。
更新されたファイル/フォルダ群に対して「検出できないときもある」というのは、状況によってまったく無反応のこともあれば、調子よく検出できることもある、というように理解していましたが(なので起動時のエラー検知を気にしていました)、
そうではなくて、大量の更新情報に対して、ときどき取りこぼしている情報がある。という感じなのですよね(ちがっていたら教えてください)。
それであれば、原理上、大量更新発生時には取りこぼすケースというのはどうしても発生します。だから仕方がないと居直るつもりはないのですが、あとはいかに取りこぼしを減らすか(同時に更新を処理する時間を少なくするか)という程度の問題になります。
現在の処理には、取りこぼしをあらかじめ想定したリカバリの処理も入れてあるのですが、行われているやり方(=サブフォルダを大量に更新する)では、うまく機能していないようです。
もしこの理解が正しければ、その観点でもっと性能を上げることができないか、検討してみます。理解が間違っているようでしたら、また教えていただけますでしょうか。
よろしくお願いします。
ありがとうございます。
細かいですが、検討の方針を考える上で大切なので(もしおわかりになれば)確認させてください。
更新のかかったポータブルディスクを差し込んだ時点で、（そのディスクを管理対象としている場合には）すぐに検知とツリー更新が始まり
この点は、TuneBrowserの動作は(4.2.4では)問題ないと理解していますが、合っていますでしょうか.
あるいはポータブルディスクから管理対象としている据え置きディスクにFastCopyやエクスプローラで同期をかけた
今回、問題となっているのは、この点ですよね.
手動Crawlであれば、おそらくほぼ取りこぼしなくDB更新しているように見受けられるので、そのあたりの振る舞いの統一を行っていただくことができればよいのでは、と門外漢ながら存じます。
手動クロール相当の動作をさせるのは簡単なのですが、あるフォルダ以下を総スキャンしますので、時間がかかりますよね。ですので、このやり方は(以前から何度かやりたい衝動には駆られるのですが)ちょっと難しいかなと思います。せっかくご提案いただいたのに、すいません。
ドライブレターを使用しています。ただしそのドライブがネットワークドライブかどうかはチェックしていますが、今回はあまり関係ありませんね。
ドライブの認識は、ドライブレターを変更したときに、OSからWM_DEVICECHANGEメッセージが発行されることが条件です。すいませんが、WM_DEVICECHANGE発行の条件はいまこの瞬間は明快ではありません。明日でよろしければ、また再確認します。
お忙しいところ、ありがとうございます。
よかったです。20分ほどかかるのはどうやねんという話はありますが(^^;…。
nikuyamaさん、こんばんわ。
本日、Crawler関係の処理を見直していて、大量の子項目が更新された場合に更新処理が重くなってしまう問題を発見しました。わたしのところでは、テストを繰り返してももともと処理抜けは認められないので、これが処理抜けに直結しているとはかぎりませんが、処理が多少軽くなったことで、処理抜けの確率は減ったものと思います。
これの対処を行った版を4.2.4.1345として先ほど公開しましたので、お手数ですが、お時間のあるときにでもお試しいただけると有難いです。
また、このリリースではこれまで公開していなかったCrawler用のパラメータを設定項目として公開しています(ツリーの「性能の設定」ページのいちばん下にあります)。もし改善していない場合、このパラメータの調整をしてみる手はありますので、またその際にはご連絡させていただければと思います。
※ 以前nikuyamaさんが、「PCの性能の問題か」とお尋ねになったときに、わたしは現象を捉え違えていたので「それはない」旨お答えしましたが、「たまに抜ける」という状況だと、その線が濃厚そうです。
nikuyamaさん、こんばんわ。
ご確認と追加の情報ありがとうございます。
わたしの確認の仕方がまずかったのだと思いますが、すこしまた混乱してきました。ファイル/フォルダが更新されて、その結果が「検出できていない」というとき、以下の2つのパターンがあると思います。
A. TuneBrowserがまったく反応せず、つまり更新検知の仕掛けそのものが動作していない。 B. TuneBrowserは反応し、読み込んでいるが、結果として読み込まれているファイルもあるが、欠落しているファイルもある。当初、A.だと理解していたのですが、その後の情報から2018-01-07 20:52に、B.のパターンなのだなと認識し、昨日リリースしたバージョンはこのB.の対策を行っています。
昨日ご連絡いただいた状況には「５．TB起動したまま、FastCopyでポータブルHDから据え置きHD(管理対象）へファイルを追加・更新 → TB反応せず（ログ０１）」とのご報告をいただいています。これは、上のパターンでいうところの、A.が発生しているということでしょうか?
あるいは、A.のこともあれば、B.のこともある、という感じでしょうか? あるいはA.でもB.でもないケースでしょうか?
A./B. で問題の所在と対策が大きく変わってきますので、お忙しいところ恐れ入りますが、ご確認いただければ幸いです。
わかりました。ありがとうございます。
アップしていただいたログには、Crawlerの定時処理とイベント処理が混交して判別できないので、次のリリースで両者のログをふたつに分けて記録するようにします。
何度もお付き合いいただいて恐縮なのですが、次からは “Crawler(Event)”というタブが登場しますので、そちらをご確認いただければと思います。どうぞよろしくお願いします。
おそれいります。
改修は終わりましたので、1時間くらいで全ビルドが完了すると思います。
いやどうか無理をなさらず、明日以降でもお時間のあるときにお願いします。m(__)m
4.2.4.1345で 終了時に動作を停止する問題が出ていますので本日のリリースは行いますが、4.2.4そのものはそんなに急いでいませんので…。
こんばんわ、仔細の情報をありがとうございます。
「もしかしてそうかな」とは思っていました。
手動クロールとの速度の差異ですが、例えば以下の構成で10,000個のファイルがFolder001からFolder100に分かれて入っているとして、
FolderRoot |-FolderA |-Folder001 |-Folder002 |- | |-Folder100Folder001から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を更新する、としたと思います)。その結果が現れているものと思います。これは緩和するようにします。
薄々わかっていたことながら、その後分析してみても、12msの処理のうち明確に1ms以上かかっている処理などはなく、1ms未満の処理を数カ所改善して、合計で2ms程度短縮できたという感じです(それでもわたしとしては、実際に改善点を見つけられたのですから、達成感は感じられる成果ではあります)。(^^;
歳のせいか、とくに夜はどうしてもアプローチが局所的になりがちなのですが、今朝出勤のために歩いているときに、昨晩から見れば「まったく違う次元のやり方」をひとつ思いつきました。複数スレッドで並列処理をさせてみようと思います。
マルチコアの時代、そんなことは常套手段であって、実際にTuneBrowserもコンバータなど多くの箇所で分散処理を行っているのですが、個人的に、ひとつのデバイス(この場合はディスク)のI/Oに対して並列処理で攻め立てるのはあまり趣味ではなく、クローラに適用することはこれまで真剣には考えてきませんでした。クロールしている間はPCの負荷が不快な状態になってしまうことも考えられます。実際、その処理をしているRAMDecodeの並列読み込みも、あまり性能改善には至れていません(RAMDecodeはユーザ操作をトリガにしてバースト的に読み込むので、PCの状態には気を遣っていません)。
ただ、12msの内訳を調べていると、そこそこCPUの処理で時間がかかっているところもありそうなので、意味がないこともなさそうだと思い至りました。
この手の処理は不具合の温床になりがちですので、すこし時間がかかるかもしれませんが、検討してみようと思います。結果として、10,000ファイル120秒が110秒になった、という話で終わるかもしれませんが。
まだほかに「まったく違う次元のやり方」があるような気はするのですが、本当に無念なことに、思いつきません。
こうしたことを再検討する機会になったことは、感謝しています。(^^) 本件、返信無用です。
nikuyamaさん、こんにちわ。
別のトピックの内容から、4.3.0の先行版をご利用いただいていると拝察します。4.3.0はクローラが並列動作するようになっていますが、本件の状況はいかがでしょうか? 後学のためにも、改善があったかどうか、教えていただけると有り難いです。
よろしくお願いします。
こんにちわ。
4.3.0で、定期クロール、イベントクロールは手動クロールとほぼおなじ動作になっています (ログの出力先などは異なりますが)。手動クロールの動作速度はあまり変わっていません。ちまちま改善はしているので、100msの処理が99msになった、というような部位はあるかもしれません(^^;。
手動クロールのほうが、ユーザの意思で対象フォルダを指定できますので、その意味では絶対に効率は良いです。
手動クロールの非同期で実行するのは、原理的には可能なのですが、競合の設計をやり直さないといけないので、道は険しいです。
よろしくお願いします。
ありがとうございます。
クローラの機能として退化している、ということですね…。無念ですが、もう一度見直してみます。
こんにちわ。
先ほど、クローラの取りこぼし対策を強化した先行版4.3.0.1351をリリースしました。お時間のあるときにでもお試しいただけると有難いです。
よろしくお願いします。
ご心配おかけしてすいませんでした。すでに復活しております。
発熱で寝ている間、何度もクローラの夢を見ました(^o^;。TuneBrowserが使い物になるかどうかのところにいると理解していますので、何とかこれで実用になるとよいのですが。
ありがとうございます。
ご無理をなさらず、お時間のあるときにお願い致します。
こんにちわ。確認いただいてありがとうございます。
おそらく、ディレクトリ名の変更は\flacから\FLACへと大小文字の変更であり、TBはUpper・Lowerの違いを区別していないからではないかと推察される。
えっと… フォルダ名の大文字小文字の変更で多重登録が発生する、というのは今回新しい話ですよね? 1月上旬ごろに問題にされていた、イベントクロールの動作速度のほうはいかがでしょうか?
それで、フォルダやファイル名の大文字小文字の区別の件なのですが、この現象は以下の状態のため発生します。
- OS(Windows)は大文字小文字を区別していない.
- TuneBrowserは大文字小文字を区別している.
OSのほうの仕様はよくご存知だと思いますが、TuneBrowserの仕様のほうは、これは動作中のさまざまな文字列比較時の効率の問題で、このようにしています。OSとTuneBrowserでここが合っていないというのは、もちろんあまりよろしくはないのですが、実際にはユーザがパス名を手入力するケースはほとんどなく、発生してもデータベースのエントリを消してもらえばいいだけの話ですので、開発着手時から8年間、この効率優先のままです。
これまであまりこの辺の仕様については、説明できていなかったかもしれないですね。質問されたこともなかったですが…。
今回やられたようなケースへの対策は、また別の課題として検討していきたいと思います。まずは基本的なクローラの動作を確定したいと思っていますので、1月ごろお話しになっていた観点で見ていただけると助かります。
いろいろとお手数をおかけします。どうぞよろしくお願いします。
ありがとうございます。
別PCで変更ずみのHDをPCに接続してTBを起動したときの検知速度
問題なのは、ドライブをマウントしたときの動作速度なのですね。こちらのほうは、定期クロールを再起動して、そのままそれに任せた状態になっていました。イベントクロールで処理するように変えてみます。
TBの場合はあるディレクトリについて更新したらちょっと休んで別のディレクトリについて更新して、また休んでみたいな動きをします
まだ本当にそのような動作をしていますでしょうか? この点は、このひと月ほどでだいぶ改善したと思うのですが…。
クロールの動作速度は、HDD/SSD/NASといったデバイスの種類や、SATA接続/USB2.0・3.0/100Mbps・1Gbpsかといった接続形態、さらにデバイスとOSのキャッシュの状態によって大きく変わります。そのため、nikuyamaさんご所望の評価基準の設定というのは残念ながら困難です。
大切なのは、nikuyamaさんが、ここで「もう少しなんとかなならんかなとの印象です」と言われていることだと思います。TuneBrowserのクロール処理が使い物にならないという状態で、終わらせたくはありません(くじけそうですが)。
こんばんわ。
途切れずにクロール処理しているものの、クロール進捗情報窓（半透明のやつ）が一定時間で消えて何かのタイミングでまた表示再開されるので、処理が途切れているように見えているだけでしょうか。
その可能性はあると思います。
ただ、今回はクロールの並列化を行ったということなので、いっぽうでGUI側の更新速度にも課題は残っているのだと思います。GUI側のキューがいっぱいになると、Crawlerは安全のためGUI更新を待つようになっており、それが「待ち」に見えている(というか「待ち」そのものですが)可能性も高いです。
ということで、いまGUI側の更新性能を上げられないか、あれこれやっています。ここは並列化のような力技はできないので、現状動作の分析とそれに対する知恵がどれだけ出せるかということなのですが、基本そんなに頭が良くないので試行錯誤です。
先ほど、高速化した先行版をアップしました。
GUI更新部分は以前とやり方を変えたので、以前とはちがう次元の動作になっていますが、そのぶん不具合がある可能性もあります…。
それと、大文字小文字問題も対処してあります。
どうぞよろしくお願いします。
ありがとうございます。
検出されない問題ですが、前回の例でご提示いただいたフォルダ構成は変わりませんか?
e:\files\flac\xxxxxxxx e:\files\MP3\xxxxxxxxこのときに、管理フォルダとして登録されているのは、”e:\files” ですか、それとも “e:\files\flac” ですか。
あと、ジャンルのほうですが、楽曲形式は何でしょうか(MP3, FLAC等々…)? ジャンルを編集したのはTuneBrowserですか、それとも別のソフトですか? 別のソフトの場合、そのソフトはジャンル番号かジャンル文字列のどちらを書き込んでいるかおわかりになりますか?(TuneBrowserはジャンル番号は認識しません)
別のトピックでもご報告されているような、認識されていなさそうなファイルがある場合、そのファイル/フォルダをTuneBrowserにExplorerからドロップすると、TuneBrowserはそのファイル群の情報を読み込んで更新します。そうした操作を行ってみていただけませんか。それでも古い情報のままでしょうか。
動作速度については、前掲のとおりです
>新規エントリーについての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:
あー、管理フォルダそのものの名前の大文字・小文字を変更されたのですね。わかりました。その観点は抜けていたかもしれません。
ジャンルのほうは、ひょっとしたらその影響かもしれません。
お忙しいところご確認ありがとうございました。
3分くらいの「ひと休み」は、私が考えていたものとはちがっていました。TuneBrowserを起動して、ドライブをマウントしたときには、以下の順番でクロール処理が走ります。
- ドライブマウントに対応したイベントクロール
- 起動後のクイッククロール
- 定時のフルクロール
これら3つは連続して動作するわけではなく、それぞれにタイミングに基いて動作します。おそらく1.2.3のどれかが走って、その後次の1.2.3のどれかが走ったのを目撃されたのだと思います。
本日ご確認いただいた状況は、問題なさそうと受け取りました。
その前にいただいた、
- 管理フォルダの大文字小文字が変わった場合の処理
- ジャンルの検出漏れ
このふたつを順番に片付けましょう。2.は1.の余波の可能性もあります。
1.のほうは、思いがけず大手術になっています。昨晩からずっと改修をつづけているのですが、なかなか手ごわいです。
4.3.0がずっと先行版のままですので、ちょっと焦ってます(^^;。
これ用に、壊れてもよいポータブルHDDも調達してきました。
Deleted, New File 云々の更新メッセージが出たことです
大文字小文字の区別が効いたとか、そういうことなのかなとも思いました。
仔細のご報告ありがとうございます。
今回、TuneBrowserのパス名の大文字小文字の区別の仕方が一部で中途半端だったという点に問題があったと思っています。大文字小文字だけが異なるファイルが登録された場合、二重に登録されて、本来のファイル名とは異なったほうのエントリが置き去りになることがあります。そしてnikuyamaの環境ではそれが「タグ変更が反映されない」エントリとして見えていた可能性があります。余波ではないかというのはそういう意味です。
今回のご報告も含めて、まずは大文字小文字の区別を厳密に取り扱えるようにして、それで様子を見ていただくということでお願いできればと考えています。
いろいろお手数をおかけしますが、どうぞよろしくお願いします。
お手数をおかけします。
今晩を予定しています。
遅くなりましたが、先ほど先行版4.3.0.1354を公開しました。
お時間のあるときに、見ていただけると助かります。どうぞよろしくお願いします。
あー、よかったです。
速報、どうもありがとうございました。感謝します。
続報します
さきほどのツリーにいないといった２ツのアルバムについて、そのカテゴリの一番上に「名無し」で登録されていました
これらのタグ付けをいろいろやってみて正しくアルバムアーティスト名のところに収まるか試してみてもよいのですが、まずはご意見（とご指示）をいただくまで、触らずにおいておきます。
よろしくお願いします。
Attachments:
こんばんわ。
続報のほうのスクリーンショットのステータスバー部分の表示から察するに、ALBUM ARTISTまたはALBUMARTISTタグのどちらかにスペースが入っていて、それが表示されているのではないかと思います。
ご確認いただけないでしょうか?
P.S. 最初のポストの添付ファイルには、バージョン情報ダイアログにnikuyamaさんの本名と思しき情報が表示されていたので、私のほうで削除しました。
別PCでは、正しく表示されていることがわかりました。
クロール時になんらかの条件があると起こるのかもしれません。
添付は、別PCのもの。
よろしくお願いします
Attachments:
続報ありがとうございます。
TAGSCANNERの出力は、おそらくすべてのタグを表示していないのではないでしょうか。”albumartist” のカラムが “ALBUMARTIST” を示しているのだとしたら、これとは別に “ALBUM ARTIST” というタグが混入していて、そこにスペースあるいはゴミデータが含まれているのではないかと推察しています。
「TuneBrowserを再起動したら正しく表示された」との情報で理解できたのですが、TuneBrowserはファイルからタグを読み取ったあと、データベースに書くときにゴミデータを除去して書き込みます。ただしその後画面に出すときには、ファイルから読んだデータをそのまま利用しているため、ゴミデータを含んだ状態で表示されてしまいます。次に再起動したときには、こんどはデータベースから読み込むため、ゴミデータが除去されていて、正しく表示されたのだろうと思います。
これは、次のリリースのときに、ファイルから読み込んだデータそのものをスクリーニングするように動作を変更したいと思います。ただ、いまちょっと4.3.0 UWP版の件でマイクロソフトと調整中で、4.3.0を更新できるか、4.3.1になるかはすいませんが微妙です。
確認してみたいので、お手数ですが、ファイルを送っていただけますか。この後、ご登録のメールアドレスに送信方法をお送りいたします。
到着していませんでした。
手づくりスクリプトですので、なにか不備があるかもしれないですが、ほかの方のファイルは到着していますので、すいませんがファイル名を変えるなどして、試してみていただけないでしょうか。
あ、大きすぎるかもしれません。
ファイル一個だけで結構ですので、お願いします。
ですので、５ツのアルバムのうち２ツにタグの不整合・ゴミなどがあったのであれば、この同期でも現象が出たPCと同じようなツリー表示になるのではないかと思います・・・
なるほど、おっしゃることがわかりました。
ファイル受領しました。追って調べてみます。
ありがとうございます。
ご指摘の通りで、ですからツリー単体の問題ではなく、アーティストの認識の問題だと捉えました。
TuneBrowserは、アーティスト名は
ALBUM ARTIST; ALBUMARTIST; ARTIST
の順で検索し、最初に値の入っていたタグを使用します。そのため、ALBUMARTISTに適切な値が入っていたとしても、ALBUM ARTISTにゴミデータが入っていると、ゴミデータが表示されます。
今回はそのケースにぴたりとハマりますので、このケースだろうと考えたのですが、お送りいただいたデータは全アルバムともアーティスト名は問題なく表示されました。
とすると? というのはまた今後です。
ちなみに、nikuyamaさんのところではもう二度と再現しないですよね?
- このトピックに返信するにはログインが必要です。