这个问题听起来非常简单但我无法找到一种方法来检查轨道uri是否正确。
例如,通过给定的有效曲目播放曲目的正常程序uri spotify:track:5Z7ygHQo02SUrFmcgpwsKW is:
1)通过sp_link_create_from_string(const char * $ track_uri)获取sp_link *
2)通过sp_link_as_track(sp_link *)获取sp_track *
3)sp_track_add_ref(sp_track *)
4)如果sp_track_error()返回SP_ERROR_OK或SP_ERROR_IS_LOADING但是metadata_updated和
SP_ERROR_OK然后sp_session_player_load和sp_session_player_play加载并播放曲目。
5)sp_track_release()和sp_session_player_unload(),当它是曲目的结尾时。
当我尝试使用正确的uri时,sp_track_error()返回SP_ERROR_IS_LOADING,
metadata_updated永远不会被调用,当然程序挂起。我检查了很多uri
并获得相同的结果。
我是否遗漏了某些内容或误解了API?
这是主循环:
pthread_mutex_lock(&g_notify_mutex);
for(;;)
{
if (next_timeout == 0)
{
while(!g_notify_do && !g_playback_done)
{
pthread_cond_wait(&g_notify_cond, &g_notify_mutex);
}
}
else
{
struct timespec ts;
#if _POSIX_TIMERS > 0
clock_gettime(CLOCK_REALTIME, &ts);
#else
struct timeval tv;
gettimeofday(&tv, NULL);
TIMEVAL_TO_TIMESPEC(&tv, &ts);
#endif
printf("%d\n",next_timeout);
if((ts.tv_nsec+(next_timeout % 1000) * 1000000)>=1000000000)
{
ts.tv_nsec += (next_timeout % 1000) * 1000000-1000000000;
ts.tv_sec += next_timeout / 1000+1;
}
else
{
ts.tv_sec += next_timeout / 1000;
ts.tv_nsec += (next_timeout % 1000) * 1000000;
}
pthread_cond_timedwait(&g_notify_cond, &g_notify_mutex, &ts);
}
g_notify_do = 0;
pthread_mutex_unlock(&g_notify_mutex);
g_currenttrack= sp_link_as_track(sp_link_create_from_string(spotify:track:1NrJYpdAi7uosDRPmSYrsG));
sp_track_add_ref(g_currenttrack);
if (sp_track_error( g_currenttrack) == SP_ERROR_OK) {
sp_session_player_load(g_sess, g_currenttrack);
sp_session_player_play(g_sess, 1);
}
do
{
sp_session_process_events(g_sess, &next_timeout);
}
while (next_timeout == 0);
pthread_mutex_lock(&g_notify_mutex);
}
我发现主循环调用了metadata_update,但是当创建了轨道时,这个循环会长时间挂起(大约290s)。
答案 0 :(得分:0)
metadata_updated
,否则不会调用 sp_session_process_events()
。您的代码停止300秒的原因是因为在登录后,sp_session_process_events()
将下一个呼叫超时设置为300秒。在第3步之后,您可以强制使用自己的通知主线程,这样可以解决问题。不幸的是我不知道为什么libspotify在这一点上不发送通知主线程。我想我们在这里都缺少一些东西。