[anonymous247]

I've been using my own video plugin in library mode (alongside my regular, non plugin library content) for a while and noticed lately that performance was degrading for video library operations (I'm running on xbox -- I know that's not supported here anymore, but I think this problem is universal to all platforms).

After a bit of investigation tonight, I found that the URLs to content returned by my plugin were still in the 'files' and 'path' tables in the videos database. Since these URLs are time-sensitive, the tables were just filling up with useless data.

Furthermore, I peeked through the thumbnail cache and found that there too were very many of the thumbnails returned from my plugin.

What I'm wondering is:

1) Is this a known issue?
2) Is there a way for my plugin to avoid adding entries to the 'files' and 'path' tables?
3) Is there a way for my plugin to ensure that it's thumbnails do not linger in the cache?

[jmarshall]

Clean Library will clean out the old URLs.

Also, you're doing it wrong if you have time-sensitive URLs - use setResolvedUrl to do it at playtime, so that your plugin:// URL (often not as time-sensitive) is saved instead.

This will also save lots of thumbs being cached.

[anonymous247]

setResolvedURL IS what my plugin uses to return URLs. And yet it is not the plugin://... value that is seen in the 'files' or 'path' table, it is rtmpe://... which is the result returned via setResolvedURL.

I can try "Clean Library" and see what effect that has. I expect it will clean the tables, but not the thumb cache.

[anonymous247]

FYI: running a library clean took care of the spurious rows in the 'files' and 'path' tables, but as i expected, the thumbnail cache files still hang around. Is there any way to prevent those from piling up?

[anonymous247]

In case it is unknown to the devs, I thought I would share how the rtmpe://... URLs end up in the files/path tables instead of the plugin://... URLs, it seems like it is attempting to save the file state for the rtmpe://... URL (maybe so that it knows what point it left off at). The callstack is below. Please note this is in a somewhat out-of-date build, so the exact details may have changed. It maybe worthwhile to not save state for web URLs.

Code:

>    XBMC.exe!CVideoDatabase::AddFile(const CStdStr<char> & strFileNameAndPath={...})  Line 540    C++
    XBMC.exe!CVideoDatabase::SetVideoSettings(const CStdStr<char> & strFilenameAndPath={...}, const CVideoSettings & setting={...})  Line 2999 + 0xc bytes    C++
    XBMC.exe!CApplication::SaveFileState()  Line 4098    C++
    XBMC.exe!CApplication::UpdateFileState()  Line 4143    C++
    XBMC.exe!CApplication::ProcessSlow()  Line 4748    C++
    XBMC.exe!CApplication::Process()  Line 4736    C++
    XBMC.exe!CGUIWindowManager::Process(bool renderOnly=false)  Line 551 + 0x17 bytes    C++
    XBMC.exe!CGUIDialog::DoModal_Internal(int iWindowID=9999, const CStdStr<char> & param={...})  Line 170    C++
    XBMC.exe!CApplicationMessenger::ProcessMessage(ThreadMessage * pMsg=0x0012ea14)  Line 514    C++
    XBMC.exe!CApplicationMessenger::SendMessageA(ThreadMessage & message={...}, bool wait=true)  Line 99    C++
    XBMC.exe!CApplicationMessenger::DoModal(CGUIDialog * pDialog=0x04dd6390, int iWindowID=9999, const CStdStr<char> & param={...})  Line 819    C++
    XBMC.exe!CGUIDialog::DoModal(int iWindowID=9999, const CStdStr<char> & param={...})  Line 217    C++
    XBMC.exe!CGUIWindowFullScreen::OnMouseEvent(const CPoint & point={...}, const CMouseEvent & event={...})  Line 620 + 0x25 bytes    C++
    XBMC.exe!CGUIControlGroup::SendMouseEvent(const CPoint & point={...}, const CMouseEvent & event={...})  Line 379 + 0x38 bytes    C++
    XBMC.exe!CGUIWindow::OnMouseAction(const CAction & action={...})  Line 386 + 0x17 bytes    C++
    XBMC.exe!CGUIWindow::OnAction(const CAction & action={...})  Line 339 + 0xc bytes    C++
    XBMC.exe!CGUIWindowFullScreen::OnAction(const CAction & action={...})  Line 467    C++
    XBMC.exe!CGUIWindowManager::OnAction(const CAction & action={...})  Line 472 + 0x13 bytes    C++
    XBMC.exe!CApplication::OnAction(const CAction & action={...})  Line 2398 + 0xe bytes    C++
    XBMC.exe!CApplication::ProcessMouse()  Line 2873 + 0x39 bytes    C++
    XBMC.exe!CApplication::OnEvent(XBMC_Event & newEvent={...})  Line 376    C++
    XBMC.exe!CWinEventsWin32::WndProc(HWND__ * hWnd=0x00111126, unsigned int uMsg=512, unsigned int wParam=0, long lParam=1507524)  Line 496 + 0xa bytes    C++

Furthermore, the thumbnails that build up seem to be generated from the plugin://... URL, not the rtmpe://... URL. For this reason, I cannot just get thumbnail name for the rtmpe://... entries in the database and try to clean only those thumbnails. Since thumbnail names come from a CRC hash of the associated file item URL, and that URL is not in the database, there is no easy way to determine which thumbnails are stale short of exhaustively determining thumbnails for all current files, and deleting everything not in that list.