【发布时间】:2014-12-11 02:14:36
【问题描述】:
为 iTunes 处理复杂的 AppleScript。一项任务是累积包含给定曲目的所有播放列表的列表。我从其他地方(选择或其他)获得了这个轨道对象。
目前,我有一个类似这样的 sn-p:
on containingPlaylists(theTrack)
tell application "iTunes"
set librarySource to the source named "Library"
set candidateLists to every user playlist in librarySource
set candidateId to (get id of theTrack)
set matchLists to {}
repeat with candidateList in candidateLists
set matchTracks to (file tracks in candidateList whose id = candidateId)
if (count of matchTracks) > 0 then
copy candidateList to end of matchLists
end if
end repeat
return matchLists
end tell
end containingPlaylists
这可行,但循环中每个播放列表都需要一个 Apple Event,这很昂贵(性能)并且会丢弃中间结果。我宁愿做的是一个查询:
set matchLists to every playlist in librarySource whose file tracks contain theTrack
但这当然不起作用(特定错误是“处理程序只处理单个对象。”但不确定这是否有见地)。我真的不确定语言/应用是否支持这样的查询。
任何人都可以确认/否认/提供任何见解吗?谢谢!
【问题讨论】:
-
你的单行查询逻辑错误:你需要使用
database ID of <track[s]>来检查两个track reference的数据是否相同。不过从结构上来说还不错;只是 iTunes 脚本模型陈旧而粗糙,在处理更复杂的查询时有点垃圾。不过,我不会太担心发送几十个 AE,因为这没什么。当发送数以万计的 AE 开销时。如果您不需要曲目引用列表,请使用exists而不是get以减少工作量,但 iTunes 的性能在解决大型库(50K+ 曲目?)上的查询时总是会下降。 -
@foo:谢谢。你能帮我构建这样一个查询吗? (在这种情况下,只需替换“theTrack 的数据库 ID”也有同样的问题。)我正在寻找包含曲目的播放列表列表(不需要返回曲目引用,只需列表引用) .我正在建立一个庞大的批量工作,其中 AE 开销将是一个大问题,我很乐意尽可能避免它。再次感谢!
-
我试过了,但 iTunes 每次都会出错;正如我所说,它解析多项目说明符的能力很差。为了最大限度地减少 AE 负载,您可以使用
tell app "iTunes" to get {database ID, id of container} of every track,它将为您提供所有曲目的数据 ID 以及包含它们的播放列表的 ID。使用NS[Counted]Set魔法有效地过滤重复的数据库 ID,使用NSDictionary将它们映射到播放列表 ID,然后使用另一个NSSet去除重复的 ID,最后从剩下的内容中构建新的playlist id <ID>引用。 -
我应该说:在您真正编写一些代码并对其进行分析之前,没有必要推测关键瓶颈might actually lie 在哪里。此外,没有足够的一般信息来了解程序的其余部分是否适用于整个解决方案,更不用说它的性能是否会对整体运行时产生显着影响。
-
谢谢@foo。有用的想法。不太担心过早的优化,主要是把它当作学习 AS/iTunes 工作方式(和不工作方式)的机会。
标签: macos applescript itunes