Deleting a video causes a segmentation fault and causes all tv recordings to be silently deleted

[William L. DeRieux IV <williamderieux@…>]

When I delete a video (not a recorded program) through the video dialog/library I get a segmentation fault and all of the recorded tv programs are silently deleted.

Steps to Reproduce:
1) Have a single video in a folder (I have no videos with metadata and all are on local on the master backend)
2) Have one or more programs recorded
3) Delete the video from step #1
4) A segmentation fault is generated
5) observed that all recorded tv files have been, silently, deleted

Here is the gdb backtrace (for the seg fault)

Program received signal SIGSEGV, Segmentation fault.
QString::startsWith (this=0x264f5d0, s=..., cs=Qt::CaseSensitive) at tools/qstring.cpp:3460
3460	tools/qstring.cpp: No such file or directory.
(gdb) bt
#0  QString::startsWith (this=0x264f5d0, s=..., cs=Qt::CaseSensitive) at tools/qstring.cpp:3460
#1  0x000000000061a901 in VideoDialog::GetCoverImage (this=0x108b800, node=0xa97f6b0)
    at videodlg.cpp:1703
#2  0x000000000061628f in VideoDialog::UpdateItem (this=0x108b800, item=0xaaed530) at videodlg.cpp:1263
#3  0x00000000006159a9 in VideoDialog::loadData (this=0x108b800) at videodlg.cpp:1218
#4  0x000000000061ea2d in VideoDialog::goBack (this=0x108b800) at videodlg.cpp:2310
#5  0x000000000061d424 in VideoDialog::keyPressEvent (this=0x108b800, levent=0x7fffffffce40)
    at videodlg.cpp:2083
#6  0x00007ffff4a9ac1c in MythMainWindow::eventFilter (this=0xc67230, e=0x7fffffffce40)
    at mythmainwindow.cpp:2100
#7  0x00007fffe9b91886 in QCoreApplicationPrivate::sendThroughObjectEventFilters (
    this=this@entry=0x9c3e00, receiver=receiver@entry=0xc67230, event=event@entry=0x7fffffffce40)
    at kernel/qcoreapplication.cpp:1065
#8  0x00007fffea41246c in QApplicationPrivate::notify_helper (this=this@entry=0x9c3e00, 
    receiver=receiver@entry=0xc67230, e=e@entry=0x7fffffffce40) at kernel/qapplication.cpp:4566
#9  0x00007fffea41a6f6 in QApplication::notify (this=<optimized out>, receiver=0xc67230, 
    e=0x7fffffffce40) at kernel/qapplication.cpp:4011
#10 0x00007fffe9b9171d in QCoreApplication::notifyInternal (this=0x9c2e80, 
    receiver=receiver@entry=0xc67230, event=event@entry=0x7fffffffce40)
    at kernel/qcoreapplication.cpp:955
#11 0x00007fffea410b36 in sendSpontaneousEvent (event=event@entry=0x7fffffffce40, 
    receiver=receiver@entry=0xc67230)
    at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
#12 qt_sendSpontaneousEvent (receiver=receiver@entry=0xc67230, event=event@entry=0x7fffffffce40)
    at kernel/qapplication.cpp:5568
#13 0x00007fffea4b4353 in QKeyMapper::sendKeyEvent (keyWidget=keyWidget@entry=0xc67230, 
    grab=grab@entry=false, type=QEvent::KeyPress, code=16777216, modifiers=..., text=..., 
    autorepeat=false, count=1, nativeScanCode=9, nativeVirtualKey=65307, nativeModifiers=16)
    at kernel/qkeymapper_x11.cpp:1866
#14 0x00007fffea4b47f2 in QKeyMapperPrivate::translateKeyEvent (this=0x7fffffffd3b0, 
    keyWidget=keyWidget@entry=0xc67230, event=0x7fff00000000, event@entry=0x7fffffffd3b0, 
    grab=grab@entry=false) at kernel/qkeymapper_x11.cpp:1836
#15 0x00007fffea48e19f in QApplication::x11ProcessEvent (this=0x9c2e80, 
    event=event@entry=0x7fffffffd3b0) at kernel/qapplication_x11.cpp:3556
#16 0x00007fffea4b6ed2 in x11EventSourceDispatch (s=0x9c6410, callback=0x0, user_data=0x0)
    at kernel/qguieventdispatcher_glib.cpp:146
#17 0x00007fffe1d80c5d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007fffe1d80f48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007fffe1d80ffc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007fffe9bc0d1d in QEventDispatcherGlib::processEvents (this=0x9c4f80, flags=...)
    at kernel/qeventdispatcher_glib.cpp:425
#21 0x00007fffea4b6f96 in QGuiEventDispatcherGlib::processEvents (this=<optimized out>, flags=...)
    at kernel/qguieventdispatcher_glib.cpp:204
#22 0x00007fffe9b90271 in QEventLoop::processEvents (this=this@entry=0x7fffffffd790, flags=...)
    at kernel/qeventloop.cpp:149
#23 0x00007fffe9b905d5 in QEventLoop::exec (this=this@entry=0x7fffffffd790, flags=...)
    at kernel/qeventloop.cpp:204
#24 0x00007fffe9b96059 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1227
#25 0x00000000004559f5 in main (argc=1, argv=0x7fffffffe0d8) at main.cpp:1786

[William L. DeRieux IV <williamderieux@…>]

Replying to William L. DeRieux IV <williamderieux@…>:

I forgot to mention this was using the fixes/0.27 branch. ​https://github.com/MythTV/mythtv/commit/a62fc0da9e9d8152a5b83cb6e8898faf67d6cbab

[Karl Egly]

Reschedule all tickets planned for, but not solved in time for, 0.27.6 to 0.27.7.

[William L. DeRieux IV <williamderieux@…>]

Even if I comment out the code (in videodlg.cpp) that causes the segmentation faults, such that it no longer is generated mythbackend still deletes all of the recorded programs int the default video storage group.

[William L. DeRieux IV <williamderieux@…>]

This seems to be corrected in the fixes/0.28 branch: ​https://github.com/MythTV/mythtv/commit/2422624fce51e4c0002af631cfbdf75105003fc9

-- no segmentation fault was generated and the recordings were not deleted.

The problem still exists in the fixes/0.27 branch though

[William L. DeRieux IV <williamderieux@…>]

Replying to William L. DeRieux IV <williamderieux@…>:

This seems to be corrected in the fixes/0.28 branch: ​https://github.com/MythTV/mythtv/commit/2422624fce51e4c0002af631cfbdf75105003fc9

-- no segmentation fault was generated and the recordings were not deleted.

The problem still exists in the fixes/0.27 branch though

I spoke too soon... I could not really even properly test the fixes/0.28 branch because I could not even record a program (gave an Arithmetic expection in the NuppleVideoRecorded? related to the video buffer size)

[JYA]

Could you provide a backtrace of this arithmetic exception?

[William L. DeRieux IV <williamderieux@…>]

Replying to jyavenard:

Could you provide a backtrace of this arithmetic exception?

Remember that this is for the fixes/0.28 branch (and is unrelated to this current ticket) -- I need to open a another ticket since this is a separate issue.

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7fffd12b8700 (LWP 4330)]
0x00007ffff53f724c in NuppelVideoRecorder::InitBuffers (this=0x7fffc40408a0)
    at recorders/NuppelVideoRecorder.cpp:944
944	    video_buffer_count = (videomegs * 1000 * 1000) / video_buffer_size;
(gdb) bt
#0  0x00007ffff53f724c in NuppelVideoRecorder::InitBuffers (this=0x7fffc40408a0)
    at recorders/NuppelVideoRecorder.cpp:944
#1  0x00007ffff53f55c4 in NuppelVideoRecorder::Initialize (this=0x7fffc40408a0)
    at recorders/NuppelVideoRecorder.cpp:764
#2  0x00007ffff53b7e3e in TVRec::TuningNewRecorder (this=0x94cdd0, streamData=0x0) at tv_rec.cpp:4233
#3  0x00007ffff53aef74 in TVRec::HandleTuning (this=0x94cdd0) at tv_rec.cpp:3509
#4  0x00007ffff539a591 in TVRec::run (this=0x94cdd0) at tv_rec.cpp:1315
#5  0x00007ffff4497ea0 in MThread::run (this=0x94d050) at mthread.cpp:319
#6  0x00007ffff4498775 in MThreadInternal::run (this=0x917e60) at mthread.cpp:79
#7  0x00007fffea585d2e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007fffea2d40a4 in start_thread (arg=0x7fffd12b8700) at pthread_create.c:309
#9  0x00007fffe97e787d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

[William L. DeRieux IV <williamderieux@…>]

Replying to William L. DeRieux IV <williamderieux@…>:

Replying to jyavenard:

Could you provide a backtrace of this arithmetic exception?

Remember that this is for the fixes/0.28 branch (and is unrelated to this current ticket) -- I need to open a another ticket since this is a separate issue.

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread 0x7fffd12b8700 (LWP 4330)]
0x00007ffff53f724c in NuppelVideoRecorder::InitBuffers (this=0x7fffc40408a0)
    at recorders/NuppelVideoRecorder.cpp:944
944	    video_buffer_count = (videomegs * 1000 * 1000) / video_buffer_size;
(gdb) bt
#0  0x00007ffff53f724c in NuppelVideoRecorder::InitBuffers (this=0x7fffc40408a0)
    at recorders/NuppelVideoRecorder.cpp:944
#1  0x00007ffff53f55c4 in NuppelVideoRecorder::Initialize (this=0x7fffc40408a0)
    at recorders/NuppelVideoRecorder.cpp:764
#2  0x00007ffff53b7e3e in TVRec::TuningNewRecorder (this=0x94cdd0, streamData=0x0) at tv_rec.cpp:4233
#3  0x00007ffff53aef74 in TVRec::HandleTuning (this=0x94cdd0) at tv_rec.cpp:3509
#4  0x00007ffff539a591 in TVRec::run (this=0x94cdd0) at tv_rec.cpp:1315
#5  0x00007ffff4497ea0 in MThread::run (this=0x94d050) at mthread.cpp:319
#6  0x00007ffff4498775 in MThreadInternal::run (this=0x917e60) at mthread.cpp:79
#7  0x00007fffea585d2e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007fffea2d40a4 in start_thread (arg=0x7fffd12b8700) at pthread_create.c:309
#9  0x00007fffe97e787d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

---

I have opened another ticket for this issue: ​https://code.mythtv.org/trac/ticket/12655

[William L. DeRieux IV <williamderieux@…>]

I was finally able to track down the root cause of this issue.

It would seem, that, when accessing the video dialog new videos are automatically refreshed without needing to explicitly scan for new videos.

However, unlike the explicit scan, the displayed videos are not inserted into the database. When you attempt to delete one of them, it attempts to do so by the video's id (which is always 0) unless you did an explicit scan and the database updated.

I have attached some patches that adds the capability -- that when the video's id is 0 it will default to deleting by the video by it's full filename instead.

-- the reason that my recorded tv programs were being deleted is because (the id for those was also 0)

[William L. DeRieux IV <williamderieux@…>]

I just wanted to update that this issue affects mththv v0.27.5 through v0.28.

[stuartm]

IMHO, it's time to kill the filesystem browsing mode for good which would fix this issue as a consequence. This mode has far too many downsides, and a percentage of users have enabled it without even being aware of the huge performance hit.

Replace it with periodic scheduled scanning or filesystem alteration monitoring - downside to the latter is that the maximum number of directories which can be monitored at a time per application is too low.

[William L. DeRieux IV <williamderieux@…>]

Replying to stuartm:

IMHO, it's time to kill the filesystem browsing mode for good which would fix this issue as a consequence. This mode has far too many downsides, and a percentage of users have enabled it without even being aware of the huge performance hit.

Replace it with periodic scheduled scanning or filesystem alteration monitoring - downside to the latter is that the maximum number of directories which can be monitored at a time per application is too low.

If you are talking about using the other browse modes: Gallery browse / list view, etc, etc

I find that the various modes are atrocious to look at (very difficult to find something). I personally like like seeing all of the videos laid out in a grid view with cover images.

I have movies in different folders and I would not want to see them all on screen (unless they were in the folder I selected).

But if the general consensus is to retire that functionally, what ideas are there for the layout theme?

[stuartm]

No I'm not talking about the different views, although it's confusingly included in the View menu. The filesystem browsing mode has no effect on the layout, but has mythvideo act like a dumb file browser instead of working from the database. This means it has no support for supplemental metadata and various features simply do not work in this mode.

It's slow as it has to re-read the file information every time - we've tried to discourage people from using it for years now but a tiny minority still wanted the feature the last time we tried to kill it.

It can be disabled from the content menu - MENU > Change View > Browse Library

[William L. DeRieux IV <williamderieux@…>]

Replying to stuartm:

No I'm not talking about the different views, although it's confusingly included in the View menu. The filesystem browsing mode has no effect on the layout, but has mythvideo act like a dumb file browser instead of working from the database. This means it has no support for supplemental metadata and various features simply do not work in this mode.

It's slow as it has to re-read the file information every time - we've tried to discourage people from using it for years now but a tiny minority still wanted the feature the last time we tried to kill it.

It can be disabled from the content menu - MENU > Change View > Browse Library

Yeah I have used the Browse library view before. The main reason I don't like it is because I have to drill-down through 4 menus to get to my movies versus only 1 with the file system browse mode.

If the browse library view could list the included folders without having to drill-down through a bunch of extra ones -- I might actually want to use it.

[stuartm]

Browse library doesn't affect content layout, that's governed by a combination of other settings.

See the 'Browse By' options.

[William L. DeRieux IV <williamderieux@…>]

Replying to stuartm:

Browse library doesn't affect content layout, that's governed by a combination of other settings.

See the 'Browse By' options.

If I select MENU -> Change view -> Browse Filesystem -- I see top-level folders that contains videos. (when in Gallery view / Browse view)

If I select MENU -> Change view -> Browse Library -- I see top-level folders that contains more folder and I have to drill-down through them to get the videos. when in Gallery view / Browse view)

If I select MENU -> Change view -> Switch to Gallery view -- I get the same folder layout (as Browse Filesystem / Browse Library)

the content is presented in a grid

If I select MENU -> Change view -> Switch to Browse view -- same as Gallery view (expect I

the content is presented in a left/right spinner that wraps around

If I select MENU -> Change view -> Switch to List view -- I get the same folder layout (as Browse Filesystem / Browse Library).

and there are no folder/content cover images. the content is presented in a list.

If I select MENU -> Change view -> Switch to Manage view -- Basiscally the same as list view

PS: the 'browse by' options only changes what content is displayed and not how it is presented.

Personally I prefer this layout:

• View -> Gallery view
• View -> Browse Filesystem
• 'Browse by' -> Folder

-- this allows me to:
1) I  don't have to navigate through several useless folders to get to the content
2) I can see everything in a grid view that makes it very easy to navigate and to see
   all of the content without abbreviation (like with the Browse library mode)
3) I see folder/video cover images without having to first select the content (as with the list views)

[William L. DeRieux IV <williamderieux@…>]

Replying to William L. DeRieux IV <williamderieux@…>:

Replying to stuartm:

Browse library doesn't affect content layout, that's governed by a combination of other settings.

See the 'Browse By' options.

If I select MENU -> Change view -> Browse Filesystem -- I see top-level folders that contains videos. (when in Gallery view / Browse view)

If I select MENU -> Change view -> Browse Library -- I see top-level folders that contains more folder and I have to drill-down through them to get the videos. when in Gallery view / Browse view)

If I select MENU -> Change view -> Switch to Gallery view -- I get the same folder layout (as Browse Filesystem / Browse Library)

the content is presented in a grid

If I select MENU -> Change view -> Switch to Browse view -- same as Gallery view (expect I

the content is presented in a left/right spinner that wraps around

If I select MENU -> Change view -> Switch to List view -- I get the same folder layout (as Browse Filesystem / Browse Library).

and there are no folder/content cover images. the content is presented in a list.

If I select MENU -> Change view -> Switch to Manage view -- Basiscally the same as list view

PS: the 'browse by' options only changes what content is displayed and not how it is presented.

Personally I prefer this layout:

• View -> Gallery view
• View -> Browse Filesystem
• 'Browse by' -> Folder

-- this allows me to:
1) I  don't have to navigate through several useless folders to get to the content
2) I can see everything in a grid view that makes it very easy to navigate and to see
   all of the content without abbreviation (like with the Browse library mode)
3) I see folder/video cover images without having to first select the content (as with the list views)

I also have it set to show to 'Show directory structure'

[stuartm]

I can only think you must have confused the two modes as what you say you are seeing is backwards. When 'Browse Filesystem' is selected you'll see more folders, not less - especially if you have multiple storage groups.

When 'Browse Filesystem' is selected you'll see 'Browse Library' in the menu and vice-versa.

Browse Library merges content from multiple storage directories - e.g. my content from four different disks is shown in one place, with no extra folders displayed. I have a root 'Films' folder and that appears in the root.

P.S. If your content is multiple directories deep then why doesn't your storage group point there instead?

[stuartm]

Screenshot of Browse Library mode

[William L. DeRieux IV <williamderieux@…>]

Replying to stuartm:

I can only think you must have confused the two modes as what you say you are seeing is backwards. When 'Browse Filesystem' is selected you'll see more folders, not less - especially if you have multiple storage groups.

When 'Browse Filesystem' is selected you'll see 'Browse Library' in the menu and vice-versa.

Browse Library merges content from multiple storage directories - e.g. my content from four different disks is shown in one place, with no extra folders displayed. I have a root 'Films' folder and that appears in the root.

P.S. If your content is multiple directories deep then why doesn't your storage group point there instead?

My default storage group points to: /home/<user>/RecordedTV/Recordings/ -- there are no other storage groups defined. I did it this way because I only by recorded tv to go there and the other videos I have are pulled from over the network as shared/smb folders.

Also mythfrontend -> setup -> media setup -> movies -> general -> Directories that hold videos -- this is where I have assigned my other video paths

[stuartm]

Ok this is the problem, you need to setup a separate Videos storage group in mythtv-setup.

[William L. DeRieux IV <williamderieux@…>]

Replying to stuartm:

Ok this is the problem, you need to setup a separate Videos storage group in mythtv-setup.

I just added the path to videos as an additional video storage group.

[William L. DeRieux IV <WilliamDeRieux@…>]

I wonder if this bug should be closed or set to invalid.

Since setting up the Videos storage groups, as stuartm had suggested, fixed the issue.

[Peter Bennett]

Closing this bug - caused by incorrect setup.