Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Arbiter]

I'm getting this weird error lately when deleting files from library, or by just deleting my now playing list



MC crashes immediately after that. This happens on a new installation, without any custom plugins, on Windows 8 Pro x64


Any clues?

[Matt]

Not sure what this might be.  First, update to the latest from the top of this board.

If it still happens, please use Help > Logging, and send the crash log to logs (at) jriver (dot) com.

Thanks.

[Arbiter]

It still happens with .178 . I captured a log with the crash and sent it to logs at jriver dot com.

[Matt]

Thanks for the log.

It doesn't actually log the crash which is strange, but there's a ton of SDK stuff going on.

Could you try disabling all your interface plugins and see if it still crashes? 

If that fixes it, enable them one-by-one to see which one causes it.

Then we'll go from there.

[Arbiter]

You were right, it was int_cad 1.00 that was causing the error. I could swear i had no plugins installed but somehow they were there.

I'm so sorry i wasted your time! I'll notify the plugin's developer about it.



Thanks a lot!

[Matt]

It could also be our fault from the COM SDK changes for v18.

I'll try to reproduce it on our side and see what we learn.

[Arbiter]

That would be nice! thanks!

[leezer3]

It could also be our fault from the COM SDK changes for v18.

I'll try to reproduce it on our side and see what we learn.

I've seen this too, and am more than happy to debug. A 100% reliable way to reproduce is to create a new library, and it dies instantly.

I can't see anything immediately wrong in the CAD code, but I'm not really a developer. More than happy to bug Poiru if required.

-Leezer-

[Matt]

I haven't been able to reproduce the crash on Windows 7 x64.

Does CAD need to be doing anything?  It's just a gray screen for me.

Creating libraries or deleting tracks doesn't seem to cause a problem.

[Arbiter]

I haven't been able to reproduce the crash on Windows 7 x64.

Does CAD need to be doing anything?  It's just a gray screen for me.

Creating libraries or deleting tracks doesn't seem to cause a problem.

CAD is just a "passthrough" plugin for CDART Display, which feeds it with playback information etc. I can reproduce leezer3's approach by creating a new library when the plugin is on.

[leezer3]

I'm on Windows 8 Pro x64 passing it through to Rainmeter.
Can crash it like clockwork- I can try a Windows 7 box if you want.
You might actually need Rainmeter/ CAD running to trigger the crash.

-Leezer-

[JimH]

Does it happen without Rainmeter?

[Arbiter]

It still happens with rainmeter unloaded from system.

[leezer3]

Yep, still crashes here without Rainmeter.
The new library crash happens with both my main library (250,000 files) and an empty new library.

-Leezer-

[leezer3]

Right, I've run up a debug build of the intcad plugin in VS2010-
The call stack suggests it's throwing a fit in IMJFileAutomation when it requests information for something that doesn't exist in the library.

I don't fully understand the code (sorry!), but when the current file changes, you send a broadcast message.
The plugin then performs a SDK callback onto the current file in the playlist to request the track info ( CJrPlugin::SendTrackInfo() )
It's throwing a fit because the data supplied as a result of this doesn't match it's expectations when the current file is null (When something has been deleted or an empty library is loaded)
The debugger starts complaining that you're feeding it unsigned integers for stuff like bitrate etc, and that's about as far as I can really go

I *suspect* this is probably a SDK bug if it's sending out junk data on null files, but equally intcad should probably be handling this better?

Who do I need to bug 

-Leezer-

[Matt]

Right, I've run up a debug build of the intcad plugin in VS2010-
The call stack suggests it's throwing a fit in IMJFileAutomation when it requests information for something that doesn't exist in the library.

I don't fully understand the code (sorry!), but when the current file changes, you send a broadcast message.
The plugin then performs a SDK callback onto the current file in the playlist to request the track info ( CJrPlugin::SendTrackInfo() )
It's throwing a fit because the data supplied as a result of this doesn't match it's expectations when the current file is null (When something has been deleted or an empty library is loaded)
The debugger starts complaining that you're feeding it unsigned integers for stuff like bitrate etc, and that's about as far as I can really go

I *suspect* this is probably a SDK bug if it's sending out junk data on null files, but equally intcad should probably be handling this better?

Who do I need to bug 

-Leezer-

I still can't get it to crash.  It shows information, then I clear the library, we return NULL from MJCurPlaylistAutomation::GetFile(...) and everything seems fine.

What's the SDK call where it gets 'unsigned integers for stuff like bitrate'?  Is it using a NULL MJFileAutomation pointer?  Maybe we used to return a file that was invalid instead of a NULL pointer?

[leezer3]

First, it gets your broadcast message containing what I I'm presuming is our junk ID in the GUID field, and promptly throws an exception:

Code: [Select]

int_cad.dll!_com_ptr_t<_com_IIID<IMJFileAutomation,&_GUID_4b6603ed_f6d4_4cfc_bde8_0ed676e5d814> >::operator->()  Line 406 C++
int_cad.dll!CJrPlugin::SendTrackInfo()  Line 165 + 0x8 bytes C++
int_cad.dll!CJrPlugin::WindowProc(HWND__ * hWnd, unsigned int uMsg, unsigned int wParam, long lParam)  Line 384 C++
Telling the debugger to continue, it cycles through each of the file properties in turn, throwing an exception for each. The first on the list is bitrate where the call stack looks like this:

Code: [Select]

int_cad.dll!_com_dispatch_propget(IDispatch * pDispatch, long dwDispID, unsigned short vtProp, void * pvProp)  Line 111 + 0x1a bytes C++
>int_cad.dll!IMJFileAutomation::GetBitrate()  Line 741 C++
int_cad.dll!CJrPlugin::SendTrackInfo()  Line 165 + 0xf bytes C++
int_cad.dll!CJrPlugin::WindowProc(HWND__ * hWnd, unsigned int uMsg, unsigned int wParam, long lParam)  Line 384 C++
Not sure whose crash this is at the minute; The library in question is totally empty, so we shouldn't have any files to even try and reference.
As I say, I don't know enough C++ to really be helpful here, but hopefully I can point things in the right direction.

-Leezer-

-Leezer-

[Matt]

So it sounds like there's a bad pointer (IMJFileAutomation).

Where is the pointer coming from?  Is it being checked for NULL?

Thanks.

[leezer3]

I believe the pointer is being checked for null; From what I can tell, this is the code that directly called it:

Code: [Select]

Interface* operator->() const
    {
        if (m_pInterface == NULL) {
            _com_issue_error(E_POINTER);
        }

        return m_pInterface;
    }Line 406 is return m_pInterface; , and this is AFAIK standard COM interface stuff

From what I can tell therefore, the pointer is the one you've just passed via the COM broadcast message recieved by the above code block.


Again, please take anything I say with a pinch or two of salt; C++ isn't something I know huge amounts about.
Is it worth pointing Poiru in this direction yet?

-Leezer-

[Matt]

I think you're one level too deep there.

Try to find where SendTrackInfo gets its IMJFileAutomation object.

[Matt]

Looking here:
https://code.google.com/p/jr-intcad/source/browse/trunk/src/JrPlugin.cpp

There's no NULL checking of file:

       IMJCurPlaylistAutomationPtr playlist = c_MjObject->GetCurPlaylist();
        IMJFileAutomationPtr file = playlist->GetFile(playlist->Position);

        WCHAR buffer[2048];
        int len = _snwprintf_s(
                buffer,
                _TRUNCATE,
                L"%s\t%s\t%s\t%s\t%ld\t\t%ld\t%u\t%s\t%ld\t%s\t\t\t\t\t\t\t%ld",
                (WCHAR*)file->Name,
                (WCHAR*)file->Artist,
                (WCHAR*)file->Album,
                (WCHAR*)file->Genre,
                file->Year,
                file->Tracknumber,
                (UINT)file->Duration,
                (WCHAR*)file->Filename,
                file->Rating * 2,
                (WCHAR*)file->GetImageFile(IMAGEFILE_DISPLAY_NO_DEFAULT),
                file->Bitrate);

        COPYDATASTRUCT cds;
        cds.cbData = (len + 1) * sizeof(WCHAR);
        cds.dwData = IPC_CURRENT_TRACK_NOTIFICATION;
        cds.lpData = (PVOID)&buffer;
        ::SendMessage(c_CadWindow, WM_COPYDATA, (WPARAM)c_Window, (LPARAM)&cds);

I would have expected this to be crash prone always.  However, maybe we could return a valid file object that just provides dummy data.  In other words, it pushes the burden of null handling into Media Center.

[leezer3]

That would be great and much appreciated solving the immediate problem, although it's not really the best long-term solution

This set of changes is the first time I've ever managed to get it to crash, so I suppose that's an achievement.
I'll try and point Poiru in this direction, and see if we can get an updated build, although I don't know whether this is likely to happen.

Cheers

-Leezer-

[poiru]

I'll try and point Poiru in this direction, and see if we can get an updated build, although I don't know whether this is likely to happen.

I will change the plugin to use an exceptionless smart pointer type (instead of _com_ptr_t) and make sure that NULLs are handled correctly. My time is limited at the moment, but I will let you know when a fix is available.

[Matt]

How would everyone feel if we integrated native CAD support into Media Center?

[Matt]

Just an FYI that MC17 also returns NULL when asking for an out-of-range file from IMJCurPlaylistAutomationPtr.  So I don't believe this is new to MC18 or caused by the SDK revisions in MC18 when we removed MFC.

[leezer3]

Further to your testing, I've now had the chance to try a Windows 7 box (The netbook :s)
I can't get it to crash on here, so something's definitely funky with the CAD/ Windows 8 combo.

I'm back to not being sure whose bug is directly responsible for the crashing 
Do you have a Windows 8 box available to test on Matt?
I'm wondering if some of your MFC changes disagree with changes in Windows 8 somewhere- I'll try getting MC17 on the Windows 8 box and see what I can learn in the next couple of days.

If you did integrate native CAD support, I think it'll only increase your potential customer base (No going and finding/ downloading the plugin, the ability to trumpet it on the wiki etc....), for a relatively small time investment

@Poiru- Massive thanks! I use this plugin on a daily basis, and a fix will be really appreciated by me and others!

-Leezer-

[Arbiter]

How would everyone feel if we integrated native CAD support into Media Center?

if you did, we would love you until the end of times! (not that we don't love you already )

[glynor]

However, maybe we could return a valid file object that just provides dummy data.  In other words, it pushes the burden of null handling into Media Center.

I think a bunch of my code uses the null reference to determine if a file exists in MC or not.

I could handle it, of course, if the dummy object was "rationally designed".  But that seems annoying to work around some other code not checking for null (which, even for my level-of-amateur seems like an amateur-hour mistake).

[6233638]

How would everyone feel if we integrated native CAD support into Media Center?

I'm not opposed to it, as long as there are no negative impacts on performance/stability - I guess it can be disabled.
It just seems like you're running third-party software to duplicate built-in functionality. (the mini-player)

But I suppose if it gives people access to a more universal skin library, which doesn't have to be the same as their main skin in Media Center, it makes a bit of sense. I don't know how widespread use of CAD is. (I hadn't heard of it until now)

Having support potentially allows someone to move from using another supported player to Media Center, and keep the skin that they are already familiar with, so that's a plus - I know that I've been trying on-and-off to figure out skinning so that I can get Media Center to look more like iTunes 11 - but I'm no artist. (so far it's just a lightly modified version of FusionX3 - which is an iTunes 10 style skin)
I would rather see people working on full skins for Media Center than CAD skins though, especially when this is a windows-only program.

Personally, I would prefer work on improving things like native taskbar integration built into Media Center to display progress, play/pause status, and album art before this.
I suppose that's also windows-only, but it falls under OS integration rather than interfacing with a third-party program.

But it sounds like this is an "easy" thing to integrate, as most of the work is already done.

[astromo]

I'm not opposed to it, as long as there are no negative impacts on performance/stability - I guess it can be disabled.
It just seems like you're running third-party software to duplicate built-in functionality. (the mini-player)

But I suppose if it gives people access to a more universal skin library, which doesn't have to be the same as their main skin in Media Center, it makes a bit of sense. I don't know how widespread use of CAD is. (I hadn't heard of it until now)

...

I would rather see people working on full skins for Media Center than CAD skins though, especially when this is a windows-only program.

Personally, I would prefer work on improving things like native taskbar integration built into Media Center to display progress, play/pause status, and album art before this.
I suppose that's also windows-only, but it falls under OS integration rather than interfacing with a third-party program.

But it sounds like this is an "easy" thing to integrate, as most of the work is already done.

I'm with 6233638, my first reaction was what is CAD? Once I bounced over through the various links I ended up in these spots:
https://github.com/poiru/jr-intcad/
http://rainmeter.net/cms/
http://cdartdisplay.com/
to be told that:

int_cad is a JRiver Media Center (and Media Jukebox) plugin which adds support for interaction with Rainmeter and CD Art Display skins.

I'm an if it ain't broke don't fix it kind of guy and have stuck with the out-of-the-box Noir (aka Henry Ford black) skin myself. I also navigate MC via the basic GUI and find that Theatre View just slows me down. Given the lack of support info for CAD, I'll give it a swerve because I've got to economise on my own time.

I'll leave the development team work out where there priorities should lie but I can't help think of what other (big) fish are out there to fry?

That said, I think 6233638 nails it from the following points around key development drivers:

• Functionality inherit to MC vs External bolt on
• Ease of reliable implementation across different operating systems

Thanks for all the good work. Keep it up..  

[leezer3]

Further to my last post, MC17 also crashes on Windows 8. Anything further I can do to test?


I'd also like to say that comparing Rainmeter to the mini-player is like comparing apples to pears 
Whilst they may both control MC's player functions, Rainmeter can do an awful lot more than just playback controls, it's far more of a desktop experience, almost a shell in it's own right.

Skim through some of the top topics in the Rainmeter 'Share Your Creations' board to see just what it can do, but I suppose in essence, it can display virtually any data anywhere.
I use a slightly chopped version of Soita for rating images playing back on my second display amongst other Rainmeter stuff, but the possibilities are infinite.

With regards to whether it's worth building native support, I think ~5 hours dev time (All of the framework is there already) is a good investment of time, but only JRiver can decide whether it works for them.

-Leezer-

[poiru]

@Poiru- Massive thanks! I use this plugin on a daily basis, and a fix will be really appreciated by me and others!

Finally had some time to work on this. If you are willing to give a fixed version a shot, download and run int_cad101-test.exe. Let me know how it works out.

[leezer3]

No crashing, really appreciated 

Otherwise appears to work nicely, although I need to give it a few days of hard use to be certain everything works as designed!
(I have very occasionally seen control signals failing to register in the past, although I've never really looked into that)

-Leezer-

[brossmac]

I would LOVE to see native support for CAD or CAD functions in MC!

(I haven't been able to get CAD working with MC for quite a few builds. Nothing seems to get fed to CAD from MC.)

[LETRA]

Finally had some time to work on this. If you are willing to give a fixed version a shot, download and run int_cad101-test.exe. Let me know how it works out.

This version don't works fine in JRiver 19 current version, on Windows 8 with Rainmeter Gnometer.

Thanks for your work.

[LETRA]

Please, posting configurations for the skin Gnometer\Media Player. I'am using this skin and have several problems. Don't works fine. Thank you.