Print

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

[Dexos]

I can not solve this problem. After I have restarted my Media Center 24 at the end of importing my library it consistently crashes every time I start the application within a few minutes. I have been fighting with this for a few weeks. I do not have the same issue on my windows machine that I am trying to retire with this dedicated linux build. Ill share below what I have tried to rule out all hardware and OS issues. I am left believing that the problem could very well be corrupt media files but even my attempts to import just subsets of my library to try and isolate what file or files are causing the problem have failed. As soon as I think I have made progress it crashes again.

I am hoping someone can offer me some suggestions to isolate my actual problem. I am not a slouch when it comes to technology. I am very familiar with hardware configurations, OS installations. 

My library is only music. No videos and no pictures.
My library I think is fairly large. Have ripped every disk I have owned and is about 16000 files in size now.
As suggested above my Windows machine has been running for years without a problem.

Started with Latest 64 bit Linux Mint and installed the "stable" version of Media Center.
   Result first experience of the crashes.
Read in this forum that Media Center was developed on Debian and installed Debian Stretch 32bit version
   Result was continued crashes.
Read in the forum that Jessie might be a better option. Installed 32 bit version of Debian Stretch
   Result was continued crashing.
Hardware elimination. put the i5 HP workstation I was building on and moved to an i5 Dell that I had.
   Result was more crashing.
Tried to install to a USB drive rather than the hard drive that the media files were on
   Result was more crashing
Realised I was unknowingly installing the 32 bit version of Debian and installed 64 bit version of Stretch (I realise now that amd64 includes intel 64bit)
   Result was more crashing
Tried the 64 bit version of Jessie
   Result was more crashing
Only 3 SATA ports on this machine so I removed the DVD Drive and installed a dedicated drive for OS so that I have 2 dedicated drives for media. (Once I am past this problem I will backup Media files from dedicated media drive A to media drive B. I have not even touched the replication strategy of this build yet)
   Result was more crashing
The more times I do this the more and more it feels like the Linux version of Media Center is struggling with either the number of files or some subtle issue with files in my library. I started looking for ways to identify possible corrupt files. I installed (I think it was called Mp3ver utility). It identified a fair number of my files with issues. Things like tags that were not formatted correctly or media length tags that were inaccurate. Let the utility correct these. I was begging to get excited, thought this might actaully be the solution
   Result is still after the first restart the Media Center crashes within a few minutes of being opened.

During all this effort I have been reviewing the Media Center logging. There never appears to be anything standing out in the logs that suggest what is the root cause of this problem.

I do get the message "Segmentation Fault" when I execute Media Center from a terminal wind. (that is the message that is written to the terminal window as it crashes.

Any suggestions to my issue are welcome. I really don't want to have to break down and install Windows on this dedicated machine I am building.

I might try looking for Mp3 inspection utilities and see if I get different results there.

In the back of my mind I cant believe that there is not a message somewhere that will get me past this

Thanks to anyone that has made it to the end of this post.


I see someone suggested posting an strace output. Pasted below

writev(8, [{"\3\0\2\0;\0\200\1\16\0\2\0;\0\200\1", 16}, {NULL, 0}, {"", 0}], 3) = 16
poll([{fd=8, events=POLLIN}], 1, 4294967295) = 1 ([{fd=8, revents=POLLIN}])
recvmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{"\1\1\270\243\3\0\0\0!\0\0\0\1\0\0\1\377\377\377\377\0\0\0\0\1\1\2\0 \0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 76
recvmsg(8, 0x7ffc75cdb9c0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(8, 0x7ffc75cdb9c0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(8, 0x7ffc75cdb9c0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(8, 0x7ffc75cdb9c0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"\17\0\2\0;\0\200\1", 8}, {NULL, 0}, {"", 0}], 3) = 8
poll([{fd=8, events=POLLIN}], 1, 4294967295) = 1 ([{fd=8, revents=POLLIN}])
recvmsg(8, {msg_name(0)=NULL, msg_iov(1)=[{"\1\0\272\243\1\0\0\0\245\0\0\0\245\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 36
recvmsg(8, 0x7ffc75cdba30, 0)           = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(8, 0x7ffc75cdba30, 0)           = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=8, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=8, revents=POLLOUT}])
writev(8, [{"H\2\261\20;\0\200\1\0\0\200\1\373\0\21\0\33\0020\0\0\30\0\0", 24}, {"\353\353\353\377\352\352\352\377\353\353\353\377\353\353\353\377\353\353\353\377\353\353\353\377\353\353\353\377\353\353\353\377"..., 17068}, {"", 0}], 3) = 17092
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000}, NULL)           = 0
recvmsg(8, 0x7ffc75cdbe10, 0)           = -1 EAGAIN (Resource temporarily unavailable)
nanosleep({0, 3000000},  <unfinished ...>
+++ killed by SIGSEGV +++
Segmentation fault
angela@Murphy:~$

[Dexos]

Overlooked BIOS, just applied current bios for machine. Was very old but most current was released in 2018...
   Result, still crashing Bet you were expecting better results

Read as well that someone disabled their network card and the problem went away. I gave this a try and guess what, the disabling of the network card has resulted in no crashing.

Was not expecting this. This has me again questioning my library files as the cause
Maybe we have conflicting network services running on the machine. Will look into this.

Could my various DLNA, and or JRiver install that also exist on my network be triggering the crash?

[Dexos]

More details

Confirmed that When the Media Network is turned off within the application the crashing also stops.

Along with the already proven fact that if I disable the network card there are also no crashes.


Disabled IP 6 for fun to see if that had any impact. No change.


Played around with hiding DLNA Dynamic Renderers in the house. No change. I will try litterally turning them all off in the house in case there is something about their chatter that is causing the problem.

Current state, I have 4000 audio tracks out of the 160000 that I poses. A-E and the Various folder. Media Network enables and network card enabled. No crashing.

[JimH]

Try turning off auto import and audio analysis.

[Dexos]

Still looking at this.

Here are the last log entries before the crash happens. Looks like successful import happened in the background.

0014081: 125822720: Database: CDataHolder::Load: Field: Edit Info; Files: 14404; Pointer bytes: 0; Data bytes: 72; Elapsed ms: 0.062
0014081: 125822720: Database: CDataHolder::Load: Field: Rotation; Files: 14404; Pointer bytes: 5360; Data bytes: 16488; Elapsed ms: 0.151
0014082: 125822720: Database: CDataHolder::Load: Field: Stack Top; Files: 14404; Pointer bytes: 0; Data bytes: 72; Elapsed ms: 0.026
0014082: 125822720: Sharing Plugins: CContentDirectoryService::Browse: Finish (3586 ms)
0014083: 125822720: Sharing Plugins: CContentDirectoryService::HandleControlFunction: Finish (3586 ms)

[bob]

What DLNA devices are on your network?

[Dexos]

DLNA Renderers that I have in the house are
   
-> The existing Windows JRiver instance
-> Ugoos UT3+ running android. There is the built in DLNA services that came with the device and its OS. As well I have tried Air Receiver as a downloaded App that historically was more stable than the one packaged with the device.

Thank you so much for your input. I have every intention of shutting them down and seeing if they were contributing to the problem.

I'll post the outcome of removing them from the network. 

[Dexos]

Try turning off auto import and audio analysis.

Thanks JimH. I am attempting your suggestion as I write this. Will update afer I see the results.

[Dexos]

Thank you Bob and Jim for your great ideas. Both of your suggestions were great additions for things to keep eliminating.

But we have an answer. At least the beginnings of an answer.
Yet another clean install, Mint with Mate this time. I was getting tired of the Debian and as the problem followed me across distros I should be safe!!

ran full import with Media Centre and ensured that it was the only computer on my network at the time. (This is getting extreme!). Played must for an hour with out a crash. If it was going to crash it was going to happen within 5 minutes of starting JRiver.

Then I turned on my Windows computer. another 20 minutes of music, no problem. Next I turned on one of my Ugoos UT3+(1 of 2) Android devices. 3 minutes passed and BANG! There is the crash. Turn UT3+(1 of 2) off and JRiver keeps running.

Next lets find out of this happens to UT3+(2 of 2) Guess what/ This one does not cause the  problem.

The difference between these 2 devices is that I recently installed a Beta OS Upgrade from Android  5.1.1 to Android 7.1.2. The new OS Appears to have 2 native DLNA Renderer services installed and running at startup. One of the 2 I can not turn off, and the second appears not to be running at the moment but keeps turning itself back on.

Solution for me is I will downgrade the OS and hope that some time in the future the problem is resolved by either us in JRiver or them on their Android platform.

Quick disclaimer!! I am not knocking Ugoos. Technology is complicated and I expect these things from time to time. Ugoos is a brand I have been using for ages. I have bought other brands but have come back because of the quality hardware. I recommend to anyone (Not running JRiver at the moment to pick one up.) It has an optical out that from my perspective gives me digital as close to the amp as I can get it.  Has been rock solid and stable. The other is in my bedroom and is my morning alarm clock.

[JimH]

Nice job of finding the source of the problem.  Thanks for reporting what you found.

[bob]

Thank you Bob and Jim for your great ideas. Both of your suggestions were great additions for things to keep eliminating.

But we have an answer. At least the beginnings of an answer.
Yet another clean install, Mint with Mate this time. I was getting tired of the Debian and as the problem followed me across distros I should be safe!!

ran full import with Media Centre and ensured that it was the only computer on my network at the time. (This is getting extreme!). Played must for an hour with out a crash. If it was going to crash it was going to happen within 5 minutes of starting JRiver.

Then I turned on my Windows computer. another 20 minutes of music, no problem. Next I turned on one of my Ugoos UT3+(1 of 2) Android devices. 3 minutes passed and BANG! There is the crash. Turn UT3+(1 of 2) off and JRiver keeps running.

Next lets find out of this happens to UT3+(2 of 2) Guess what/ This one does not cause the  problem.

The difference between these 2 devices is that I recently installed a Beta OS Upgrade from Android  5.1.1 to Android 7.1.2. The new OS Appears to have 2 native DLNA Renderer services installed and running at startup. One of the 2 I can not turn off, and the second appears not to be running at the moment but keeps turning itself back on.

Solution for me is I will downgrade the OS and hope that some time in the future the problem is resolved by either us in JRiver or them on their Android platform.

Quick disclaimer!! I am not knocking Ugoos. Technology is complicated and I expect these things from time to time. Ugoos is a brand I have been using for ages. I have bought other brands but have come back because of the quality hardware. I recommend to anyone (Not running JRiver at the moment to pick one up.) It has an optical out that from my perspective gives me digital as close to the amp as I can get it.  Has been rock solid and stable. The other is in my bedroom and is my morning alarm clock.

Thanks for the detailed report.
This sounds very similar to an issue we solved with a Android app earlier. It's probably going to take getting something like that running here so we can catch it in the debugger.

[Dexos]

Thanks for the detailed report.
This sounds very similar to an issue we solved with a Android app earlier. It's probably going to take getting something like that running here so we can catch it in the debugger.

What I should not have done was downgrade the android box so quickly. I could upgrade the device again if we think a review of a tcpdump would help.

[Dexos]

Thanks for the detailed report.
This sounds very similar to an issue we solved with a Android app earlier. It's probably going to take getting something like that running here so we can catch it in the debugger.

What was the application that caused the issue. I believe that in my case it was an app called "eHomeMediaCenter"

I am only partially sure of that. There was also a "DLNA" app that was also packaged with the upgraded OS.

[bob]

What was the application that caused the issue. I believe that in my case it was an app called "eHomeMediaCenter"

I am only partially sure of that. There was also a "DLNA" app that was also packaged with the upgraded OS.

This was the thread from May:
https://yabb.jriver.com/interact/index.php/topic,113536.0.html

Maybe check that out and see if any of it might apply?

If you could run a windows build and reproduce the crash we might get a useful dump file. That's how we tracked the last one down.