Mailing List Archive

>
> The app is slow to start and to stop (talking 20, 30 seconds)
>

I can get startup down to 14 sec and exit down to 2 sec if you disable upnp
(--noupnp). I'm not sure what the other 14sec delay is (I think either
database or QT video) - but come on, how fast do you want this thing to
load? On my older intel NUC mythbuntu takes around this amount of time to
load mythfrontend.


> Cutlist editor core dumps *every time* editing a HD (h254) recording
>

I'm not experiencing this error. A log snippet and the crash report would
be helpful


> On linux scan of video fills in meta data. On macos it often does not.
> I->Change Details->Retrieve often works, often on 2nd or 3rd try. Sometimes
> at least the text is set but the image is not
>

I had similar issues on mythbuntu. The latest round of metadata patches
seemed to have fixed some of the issues. I also suspect thetvdb was
having issues with their api on multiple occasions.

I shall post to macports to see if any interest is stirred
>

I suspect that they will point you to Craig who is on this list and the
forums (and is a great help).

> On 30 Dec 2020, at 3:52 am, John Hoyt <john.hoyt@gmail.com> wrote:
>
> The app is slow to start and to stop (talking 20, 30 seconds)
>
> I can get startup down to 14 sec and exit down to 2 sec if you disable upnp (--noupnp). I'm not sure what the other 14sec delay is (I think either database or QT video) - but come on, how fast do you want this thing to load? On my older intel NUC mythbuntu takes around this amount of time to load mythfrontend.
>
> Cutlist editor core dumps *every time* editing a HD (h254) recording
>
> I'm not experiencing this error. A log snippet and the crash report would be helpful

I now 'never' use the cutlist-editor on my mac frontend. I did by accident abd it worked perfectly. I edited a knowb bad recording and it failed immediatly.

Input #0, avi, from '/store/Movies/Myth-F/The Future of Work.avi':
Metadata:
encoder : Lavf58.29.100
Duration: 00:51:08.18, start: 0.000000, bitrate: 3557 kb/s
Stream #0:0: Video: h264 (High) (H264 / 0x34363248), yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 3344 kb/s, 50 fps, 25 tbr, 50 tbn, 50 tbc
Stream #0:1: Audio: mp2 (P[0][0][0] / 0x0050), 48000 Hz, stereo, s16p, 192 kb/s



Input #0, mpegts, from '/store/10070_20210123131900.ts':
Duration: 02:41:00.84, start: 6021.609933, bitrate: 5186 kb/s
Stream #0:0[0x641]: Video: h264 (High), yuv420p(tv, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x643](eng): Audio: ac3, 48000 Hz, stereo, fltp, 384 kb/s
Stream #0:2[0x644](eng): Subtitle: dvb_teletext


The second which fails, (always, ie every recording) has a high count of errors

. . .
[h264 @ 0x10a3bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x10a3bc0] non-existing PPS 0 referenced
[h264 @ 0x10a3bc0] decode_slice_header error
[h264 @ 0x10a3bc0] no frame!
[h264 @ 0x10a3bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x10a3bc0] non-existing PPS 0 referenced
[h264 @ 0x10a3bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x10a3bc0] non-existing PPS 0 referenced
[h264 @ 0x10a3bc0] decode_slice_header error
[h264 @ 0x10a3bc0] no frame!
[h264 @ 0x10a3bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x10a3bc0] non-existing PPS 0 referenced
[h264 @ 0x10a3bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x10a3bc0] non-existing PPS 0 referenced
[h264 @ 0x10a3bc0] decode_slice_header error
[h264 @ 0x10a3bc0] no frame!
[mpegts @ 0x109fb80] PES packet size mismatch


What logging would help? this is 'all'

. . .
2021-01-25 07:26:32.815671 I AOBase: SetAudiotime atc=6587497 tc=6587465 f=1536 pfu=0 pfs=0
2021-01-25 07:26:32.815680 I AFD: audio timecode 592871934 592871934 6587465 6587497
2021-01-25 07:26:32.815744 I MythSocket(7fb3c0f63e80:121): write -> 121 50 QUERY_FILETRANSFER 103[]:[]REQUEST_BLOCK[]:[]32768
2021-01-25 07:26:32.822165 I MythSocket(7fb3c0f63e80:121): read <- 121 5 32768
2021-01-25 07:26:32.822311 I AOBase: AddData frames=1536, bytes=12288, used=233473, free=10006463, timecode=6587497 needsupmix=0
2021-01-25 07:26:32.822353 I AOBase: SetAudiotime atc=6587529 tc=6587497 f=1536 pfu=0 pfs=0
2021-01-25 07:26:32.822366 I AFD: audio timecode 592874814 592874814 6587497 6587529
2021-01-25 07:26:32.822465 I AOBase: AddData frames=1536, bytes=12288, used=245761, free=9994175, timecode=6587529 needsupmix=0
2021-01-25 07:26:32.822491 I AOBase: SetAudiotime atc=6587561 tc=6587529 f=1536 pfu=0 pfs=0
2021-01-25 07:26:32.822503 I AFD: audio timecode 592877694 592877694 6587529 6587561
2021-01-25 07:26:32.822617 I AOBase: AddData frames=1536, bytes=12288, used=258049, free=9981887, timecode=6587561 needsupmix=0
2021-01-25 07:26:32.822743 I AOBase: SetAudiotime atc=6587593 tc=6587561 f=1536 pfu=0 pfs=0
2021-01-25 07:26:32.822756 I AFD: audio timecode 592880574 592880574 6587561 6587593
2021-01-25 07:26:32.822824 I MythSocket(7fb3c0f63e80:121): write -> 121 50 QUERY_FILETRANSFER 103[]:[]REQUEST_BLOCK[]:[]32768
2021-01-25 07:26:32.828932 I AOG::GetImage(6588166) using [6587553..6587593] avail [6586889..6587593]
2021-01-25 07:26:32.829095 I MythSocket(7fb3c0f63e80:121): read <- 121 5 32768
2021-01-25 07:26:32.829296 I AOBase: AddData frames=1536, bytes=12288, used=270337, free=9969599, timecode=6587593 needsupmix=0
Handling Segmentation fault: 11
/Applications/Mythfrontend.app/Contents/MacOS/mythfrontend: line 15: 33234 Segmentation fault: 11 ./mythfrontend.real $@

This does not segfault on linux
James

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

>
> I now 'never' use the cutlist-editor on my mac frontend. I did by accident
> abd it worked perfectly. I edited a knowb bad recording and it failed
> immediatly


Can you share any insight into what makes the recording "known bad? - i.e.
what caused it to be in the bad state"


> . . .
>
2021-01-25 07:26:32.815671 I AOBase: SetAudiotime atc=6587497 tc=6587465
> f=1536 pfu=0 pfs=0
> 2021-01-25 07:26:32.815680 I AFD: audio timecode 592871934 592871934
> 6587465 6587497
> 2021-01-25 07:26:32.815744 I MythSocket(7fb3c0f63e80:121): write -> 121
> 50 QUERY_FILETRANSFER 103[]:[]REQUEST_BLOCK[]:[]32768
> 2021-01-25 07:26:32.822165 I MythSocket(7fb3c0f63e80:121): read <- 121
> 5 32768
> 2021-01-25 07:26:32.822311 I AOBase: AddData frames=1536, bytes=12288,
> used=233473, free=10006463, timecode=6587497 needsupmix=0
> 2021-01-25 07:26:32.822353 I AOBase: SetAudiotime atc=6587529 tc=6587497
> f=1536 pfu=0 pfs=0
> 2021-01-25 07:26:32.822366 I AFD: audio timecode 592874814 592874814
> 6587497 6587529
> 2021-01-25 07:26:32.822465 I AOBase: AddData frames=1536, bytes=12288,
> used=245761, free=9994175, timecode=6587529 needsupmix=0
> 2021-01-25 07:26:32.822491 I AOBase: SetAudiotime atc=6587561 tc=6587529
> f=1536 pfu=0 pfs=0
> 2021-01-25 07:26:32.822503 I AFD: audio timecode 592877694 592877694
> 6587529 6587561
> 2021-01-25 07:26:32.822617 I AOBase: AddData frames=1536, bytes=12288,
> used=258049, free=9981887, timecode=6587561 needsupmix=0
> 2021-01-25 07:26:32.822743 I AOBase: SetAudiotime atc=6587593 tc=6587561
> f=1536 pfu=0 pfs=0
> 2021-01-25 07:26:32.822756 I AFD: audio timecode 592880574 592880574
> 6587561 6587593
> 2021-01-25 07:26:32.822824 I MythSocket(7fb3c0f63e80:121): write -> 121
> 50 QUERY_FILETRANSFER 103[]:[]REQUEST_BLOCK[]:[]32768
> 2021-01-25 07:26:32.828932 I AOG::GetImage(6588166) using
> [6587553..6587593] avail [6586889..6587593]
> 2021-01-25 07:26:32.829095 I MythSocket(7fb3c0f63e80:121): read <- 121
> 5 32768
> 2021-01-25 07:26:32.829296 I AOBase: AddData frames=1536, bytes=12288,
> used=270337, free=9969599, timecode=6587593 needsupmix=0
> Handling Segmentation fault: 11
> /Applications/Mythfrontend.app/Contents/MacOS/mythfrontend: line 15: 33234
> Segmentation fault: 11 ./mythfrontend.real $@
>

Unfortunately the output wasn't as informative as I hoped (all is
probably the best we can output). One of the devs (Mark?) might have a
better suggestion on how to debug the issue.

When the application crashes, does it bring up a macOS crash report
window? i.e. one that asks you to send feedback to Apple? If so, that
crash report would be helpful as it probably will shed some light on the
dylib that segfaulted


> This does not segfault on linux
>

...I guess linux gets either a cookie or a gold star for the day as a
reward...

I post the (one of the) movies that seq faults then a link.

Their taps are big so download speed at your limit, my upload is much slower (6mb/s) so till tomorrow

James

> On 26 Jan 2021, at 8:31 pm, John Hoyt <john.hoyt@gmail.com> wrote:
>
> I now 'never' use the cutlist-editor on my mac frontend. I did by accident abd it worked perfectly. I edited a knowb bad recording and it failed immediatly
>
> Can you share any insight into what makes the recording "known bad? - i.e. what caused it to be in the bad state"
>
> . . .
> 2021-01-25 07:26:32.815671 I AOBase: SetAudiotime atc=6587497 tc=6587465 f=1536 pfu=0 pfs=0
> 2021-01-25 07:26:32.815680 I AFD: audio timecode 592871934 592871934 6587465 6587497
> 2021-01-25 07:26:32.815744 I MythSocket(7fb3c0f63e80:121): write -> 121 50 QUERY_FILETRANSFER 103[]:[]REQUEST_BLOCK[]:[]32768
> 2021-01-25 07:26:32.822165 I MythSocket(7fb3c0f63e80:121): read <- 121 5 32768
> 2021-01-25 07:26:32.822311 I AOBase: AddData frames=1536, bytes=12288, used=233473, free=10006463, timecode=6587497 needsupmix=0
> 2021-01-25 07:26:32.822353 I AOBase: SetAudiotime atc=6587529 tc=6587497 f=1536 pfu=0 pfs=0
> 2021-01-25 07:26:32.822366 I AFD: audio timecode 592874814 592874814 6587497 6587529
> 2021-01-25 07:26:32.822465 I AOBase: AddData frames=1536, bytes=12288, used=245761, free=9994175, timecode=6587529 needsupmix=0
> 2021-01-25 07:26:32.822491 I AOBase: SetAudiotime atc=6587561 tc=6587529 f=1536 pfu=0 pfs=0
> 2021-01-25 07:26:32.822503 I AFD: audio timecode 592877694 592877694 6587529 6587561
> 2021-01-25 07:26:32.822617 I AOBase: AddData frames=1536, bytes=12288, used=258049, free=9981887, timecode=6587561 needsupmix=0
> 2021-01-25 07:26:32.822743 I AOBase: SetAudiotime atc=6587593 tc=6587561 f=1536 pfu=0 pfs=0
> 2021-01-25 07:26:32.822756 I AFD: audio timecode 592880574 592880574 6587561 6587593
> 2021-01-25 07:26:32.822824 I MythSocket(7fb3c0f63e80:121): write -> 121 50 QUERY_FILETRANSFER 103[]:[]REQUEST_BLOCK[]:[]32768
> 2021-01-25 07:26:32.828932 I AOG::GetImage(6588166) using [6587553..6587593] avail [6586889..6587593]
> 2021-01-25 07:26:32.829095 I MythSocket(7fb3c0f63e80:121): read <- 121 5 32768
> 2021-01-25 07:26:32.829296 I AOBase: AddData frames=1536, bytes=12288, used=270337, free=9969599, timecode=6587593 needsupmix=0
> Handling Segmentation fault: 11
> /Applications/Mythfrontend.app/Contents/MacOS/mythfrontend: line 15: 33234 Segmentation fault: 11 ./mythfrontend.real $@
>
> Unfortunately the output wasn't as informative as I hoped (all is probably the best we can output). One of the devs (Mark?) might have a better suggestion on how to debug the issue.
>
> When the application crashes, does it bring up a macOS crash report window? i.e. one that asks you to send feedback to Apple? If so, that crash report would be helpful as it probably will shed some light on the dylib that segfaulted
>
> This does not segfault on linux
>
> ...I guess linux gets either a cookie or a gold star for the day as a reward...
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

This is not a clip I'd cut, but it is small and shows the issue

As far as I can tell *any* edit crashes but this is what I did
I guess the easiest way to do this is to scan it as a movie then
[play]
E
<sp>
<up> or <down> to select 1min
<rt><rt>crash

My linux frontends do not do this. I run a VM on the mac just to cutlist edit.

http://tigger.ws/downloads/10074_20210123140800.ts

James

> On 26 Jan 2021, at 10:41 pm, James Linder <jam@tigger.ws> wrote:
>
> I post the (one of the) movies that seq faults then a link.
>
> Their taps are big so download speed at your limit, my upload is much slower (6mb/s) so till tomorrow
>
> James
>
>> On 26 Jan 2021, at 8:31 pm, John Hoyt <john.hoyt@gmail.com> wrote:
>>
>> I now 'never' use the cutlist-editor on my mac frontend. I did by accident abd it worked perfectly. I edited a knowb bad recording and it failed immediatly
>>
>> Can you share any insight into what makes the recording "known bad? - i.e. what caused it to be in the bad state"
>>
>> . . .
>> 2021-01-25 07:26:32.815671 I AOBase: SetAudiotime atc=6587497 tc=6587465 f=1536 pfu=0 pfs=0
>> 2021-01-25 07:26:32.815680 I AFD: audio timecode 592871934 592871934 6587465 6587497
>> 2021-01-25 07:26:32.815744 I MythSocket(7fb3c0f63e80:121): write -> 121 50 QUERY_FILETRANSFER 103[]:[]REQUEST_BLOCK[]:[]32768
>> 2021-01-25 07:26:32.822165 I MythSocket(7fb3c0f63e80:121): read <- 121 5 32768
>> 2021-01-25 07:26:32.822311 I AOBase: AddData frames=1536, bytes=12288, used=233473, free=10006463, timecode=6587497 needsupmix=0
>> 2021-01-25 07:26:32.822353 I AOBase: SetAudiotime atc=6587529 tc=6587497 f=1536 pfu=0 pfs=0
>> 2021-01-25 07:26:32.822366 I AFD: audio timecode 592874814 592874814 6587497 6587529
>> 2021-01-25 07:26:32.822465 I AOBase: AddData frames=1536, bytes=12288, used=245761, free=9994175, timecode=6587529 needsupmix=0
>> 2021-01-25 07:26:32.822491 I AOBase: SetAudiotime atc=6587561 tc=6587529 f=1536 pfu=0 pfs=0
>> 2021-01-25 07:26:32.822503 I AFD: audio timecode 592877694 592877694 6587529 6587561
>> 2021-01-25 07:26:32.822617 I AOBase: AddData frames=1536, bytes=12288, used=258049, free=9981887, timecode=6587561 needsupmix=0
>> 2021-01-25 07:26:32.822743 I AOBase: SetAudiotime atc=6587593 tc=6587561 f=1536 pfu=0 pfs=0
>> 2021-01-25 07:26:32.822756 I AFD: audio timecode 592880574 592880574 6587561 6587593
>> 2021-01-25 07:26:32.822824 I MythSocket(7fb3c0f63e80:121): write -> 121 50 QUERY_FILETRANSFER 103[]:[]REQUEST_BLOCK[]:[]32768
>> 2021-01-25 07:26:32.828932 I AOG::GetImage(6588166) using [6587553..6587593] avail [6586889..6587593]
>> 2021-01-25 07:26:32.829095 I MythSocket(7fb3c0f63e80:121): read <- 121 5 32768
>> 2021-01-25 07:26:32.829296 I AOBase: AddData frames=1536, bytes=12288, used=270337, free=9969599, timecode=6587593 needsupmix=0
>> Handling Segmentation fault: 11
>> /Applications/Mythfrontend.app/Contents/MacOS/mythfrontend: line 15: 33234 Segmentation fault: 11 ./mythfrontend.real $@
>>
>> Unfortunately the output wasn't as informative as I hoped (all is probably the best we can output). One of the devs (Mark?) might have a better suggestion on how to debug the issue.
>>
>> When the application crashes, does it bring up a macOS crash report window? i.e. one that asks you to send feedback to Apple? If so, that crash report would be helpful as it probably will shed some light on the dylib that segfaulted
>>
>> This does not segfault on linux
>>
>> ...I guess linux gets either a cookie or a gold star for the day as a reward...
>> _______________________________________________
>> mythtv-users mailing list
>> mythtv-users@mythtv.org
>> http://lists.mythtv.org/mailman/listinfo/mythtv-users
>> http://wiki.mythtv.org/Mailing_List_etiquette
>> MythTV Forums: https://forum.mythtv.org
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 27/01/2021 05:06, James Linder wrote:
> This is not a clip I'd cut, but it is small and shows the issue
>
> As far as I can tell *any* edit crashes but this is what I did
> I guess the easiest way to do this is to scan it as a movie then
> [play]
> E
> <sp>
> <up> or <down> to select 1min
> <rt><rt>crash
>
> My linux frontends do not do this. I run a VM on the mac just to cutlist edit.
>
> http://tigger.ws/downloads/10074_20210123140800.ts
>
> James

It might be relevant that I had crashes in the cutlist editor in linux
master around the beginning of November last year. The crashes got
fixed within a week or so, but it's still easy to provoke a 20 second
hangup. I don't know what version the mac build is using...

John P
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

> On 27 Jan 2021, at 5:04 pm, John Pilkington <johnpilk222@gmail.com> wrote:
>
> On 27/01/2021 05:06, James Linder wrote:
>> This is not a clip I'd cut, but it is small and shows the issue
>> As far as I can tell *any* edit crashes but this is what I did
>> I guess the easiest way to do this is to scan it as a movie then
>> [play]
>> E
>> <sp>
>> <up> or <down> to select 1min
>> <rt><rt>crash
>> My linux frontends do not do this. I run a VM on the mac just to cutlist edit.
>> http://tigger.ws/downloads/10074_20210123140800.ts
>> James
>
> It might be relevant that I had crashes in the cutlist editor in linux master around the beginning of November last year. The crashes got fixed within a week or so, but it's still easy to provoke a 20 second hangup. I don't know what version the mac build is using…
>
[haycorn] /Users/jam [540]% /Applications/Mythfrontend.app/Contents/MacOS/mythfrontend --version
Please attach all output as a file in bug reports.
MythTV Version : v31.0-118-geb3c84de5f
MythTV Branch : fixes/31
Network Protocol : 91
Library API : 31.20200101-1
QT Version : 5.14.2
Options compiled in:

James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 27/01/2021 09:17, James Linder wrote:
>
>
>> On 27 Jan 2021, at 5:04 pm, John Pilkington <johnpilk222@gmail.com> wrote:
>>
>> On 27/01/2021 05:06, James Linder wrote:
>>> This is not a clip I'd cut, but it is small and shows the issue
>>> As far as I can tell *any* edit crashes but this is what I did
>>> I guess the easiest way to do this is to scan it as a movie then
>>> [play]
>>> E
>>> <sp>
>>> <up> or <down> to select 1min
>>> <rt><rt>crash
>>> My linux frontends do not do this. I run a VM on the mac just to cutlist edit.
>>> http://tigger.ws/downloads/10074_20210123140800.ts
>>> James
>>
>> It might be relevant that I had crashes in the cutlist editor in linux master around the beginning of November last year. The crashes got fixed within a week or so, but it's still easy to provoke a 20 second hangup. I don't know what version the mac build is using…
>>
> [haycorn] /Users/jam [540]% /Applications/Mythfrontend.app/Contents/MacOS/mythfrontend --version
> Please attach all output as a file in bug reports.
> MythTV Version : v31.0-118-geb3c84de5f
> MythTV Branch : fixes/31
> Network Protocol : 91
> Library API : 31.20200101-1
> QT Version : 5.14.2
> Options compiled in:
>
> James

My crashes started after a big packet of commits. The 'partial' fix ( 2
Nov ) appeared to be

https://github.com/MythTV/mythtv/commit/4bd6276


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

>
> > [haycorn] /Users/jam [540]%
> /Applications/Mythfrontend.app/Contents/MacOS/mythfrontend --version
> > Please attach all output as a file in bug reports.
> > MythTV Version : v31.0-118-geb3c84de5f
> > MythTV Branch : fixes/31
> > Network Protocol : 91
> > Library API : 31.20200101-1
> > QT Version : 5.14.2
> > Options compiled in:
>

James, it looks like you're on an older version as I've been building with
QT 5.15.2 for a few months now (I think around Nov). Can you grab one of
the more recent versions off of sourceforge and see if this helps some
(that version of QT had quite a few updates and patches for macOS)? If it
does great, if not, I can look into backporting the master partial fix to
v31 like I did with the audio updates a couple months ago when Big Sur
broke everything.

The sourceforge build for Big Sur (v31) is up to date with the latest
github commit. The Catalina and High Sierra builds are a bit behind (by
only a commit or two) as I'm waiting on some macports team to accept some
upstream updates. Once macports accepts the updates I'll be rebuilding for
the older OSes.

Also can you run the following command and give me the output (it will
print out your macOS version and Xcode version).

printf "%s\n" "macOS $(sw_vers -productVersion) $(sw_vers -buildVersion)"
"$(xcodebuild -version|awk 'NR==1{x=$0}END{print x" "$NF}')"|tee
/dev/tty|pbcopy


I'm curious what macOS / Xcode environment you're running on as a
difference there may give me some hint on later troubleshooting steps.

My crashes started after a big packet of commits. The 'partial' fix ( 2
> Nov ) appeared to be
>

Thanks John! I'll take a look to see if this will help when I investigate
James' issue later in the week.

> On 27 Jan 2021, at 7:54 pm, John Hoyt <john.hoyt@gmail.com> wrote:
>
> printf "%s\n" "macOS $(sw_vers -productVersion) $(sw_vers -buildVersion)" "$(xcodebuild -version|awk 'NR==1{x=$0}END{print x" "$NF}')"|tee /dev/tty|pbcopy

macOS 10.15.7 19H2
Xcode 11.3.1 11C504

I use parallels lots and without doubt they did lots of work to accomadate Big Sur, but I;m not going to upgrade. I ran a Big Sur in a VM. From a technical (as opposed to 'now we join your facebook account . . .') I see no compelling reason.

I'll grab a new build now, I've been using the build I made when you did all the ansible stuff and the 1/4 size fix.

I'm sure that my chan-7 ota recordings are damaged, but the linux fe copes.

James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

> On 27 Jan 2021, at 7:54 pm, John Hoyt <john.hoyt@gmail.com> wrote:
>
> printf "%s\n" "macOS $(sw_vers -productVersion) $(sw_vers -buildVersion)" "$(xcodebuild -version|awk 'NR==1{x=$0}END{print x" "$NF}')"|tee /dev/tty|pbcopy

I grabbed your catelina build.
better ...
start 8 secs
quit 6 secs
edit coredumps

James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

>
> I use parallels lots and without doubt they did lots of work to accomadate
> Big Sur, but I;m not going to upgrade. I ran a Big Sur in a VM. From a
> technical (as opposed to 'now we join your facebook account . . .') I see
> no compelling reason.
>

Well, I kinda like getting security patches myself. Apple tends to apply
more focus to the latest releases and only patches the "big known" stuff on
older OSes

I'm sure that my chan-7 ota recordings are damaged, but the linux fe copes.
>

Yep - ffmpeg (on linux) certainly is complaining a LOT about that file.
I'm out of time to keep looking today, but will investigate the cutlist
issue probably this weekend. Hopefully I can come up with a solution.

As a stop gap, you could write a post recording script that repairs /
transcodes the recordings for that specific channel. Patching mythtv is
certainly one solution here, but in the end that recording (and it sounds
like anything captured from that channel) is most definitely messed up and
should be fixed as well.

>
> I grabbed your catelina build.
> better ...
>

good - it should also have some (not all) improvements to the metadata
grabbers. The rest will come when I upload new builds after the macports
updates get committed.


> start 8 secs
> quit 6 secs
>

Was this with upnp on or off?


> edit coredumps
>

That's not really a surprise. Will look into it more when I have time. I
will reiterate - you should fix the recordings from that channel with a
transcode script. They are broken and it's tough for any dev to anticipate
and code up solutions for all of the potential ways a recording can get
corrupted.

> On 27 Jan 2021, at 8:29 pm, John Hoyt <john.hoyt@gmail.com> wrote:
>
> I use parallels lots and without doubt they did lots of work to accomadate Big Sur, but I;m not going to upgrade. I ran a Big Sur in a VM. From a technical (as opposed to 'now we join your facebook account . . .') I see no compelling reason.
>
> Well, I kinda like getting security patches myself. Apple tends to apply more focus to the latest releases and only patches the "big known" stuff on older OSes
>
> I'm sure that my chan-7 ota recordings are damaged, but the linux fe copes.
>
> Yep - ffmpeg (on linux) certainly is complaining a LOT about that file. I'm out of time to keep looking today, but will investigate the cutlist issue probably this weekend. Hopefully I can come up with a solution.
>
> As a stop gap, you could write a post recording script that repairs / transcodes the recordings for that specific channel. Patching mythtv is certainly one solution here, but in the end that recording (and it sounds like anything captured from that channel) is most definitely messed up and should be fixed as well.

I've been doing my editing in a VM, but transcoding may well be the answer.
I'll investigate. A lossless cut is NOT the answer, a byte by byte rebuild is what is needed (ideas anyone)(ffmpeg ??).

BTW I'm 10 km from transmitter site, with a professionally installed multi-element external antenna running type N cable by a clueless tech who had no idea of the effect of "another access plug"

But the problem is not limited to a single channel, but interestingly all the 200MHz channels (OK 186, 223 etc) have an issue, the 500MHz did not.

James

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

> On 27 Jan 2021, at 8:57 pm, John Hoyt <john.hoyt@gmail.com> wrote:
>
> I grabbed your catelina build.
> better ...
>
> good - it should also have some (not all) improvements to the metadata grabbers. The rest will come when I upload new builds after the macports updates get committed.
>
> start 8 secs
> quit 6 secs
>
> Was this with upnp on or off?

How do you turn it on/off ?

James

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, 27 Jan 2021 at 13:07, James Linder <jam@tigger.ws> wrote:
> How do you turn it on/off ?

mythfrontend --noupnp

fwiw - I'm happy to help where I can in getting this fixed - but my 12
year old macbook is now officially dead; so no macos builds here
anymore. Happy to commit fixes though:)

John - do you have any debug builds?

Regards
Mark
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

> On 27 Jan 2021, at 9:12 pm, Mark Kendall <mark.kendall@gmail.com> wrote:
>
> On Wed, 27 Jan 2021 at 13:07, James Linder <jam@tigger.ws> wrote:
>> How do you turn it on/off ?
>
> mythfrontend --noupnp
>
> fwiw - I'm happy to help where I can in getting this fixed - but my 12
> year old macbook is now officially dead; so no macos builds here
> anymore. Happy to commit fixes though:)
>
> John - do you have any debug builds?

OK thank you

start 8 secs --noupnp 6 secs
stop 6 secs --noupnp 0.25 sec

Mark
if you follow John's ansible instructions
https://github.com/MythTV/packaging/tree/master/OSX/build/macports_ansible
then building is straight forward

James

PS I've done my building in parallels VM. You can even make a Big Sur VM on catelina.
The only chicken-n-egg gotcha in Johns build is the build script is loaded by the build script. Can't recall my work around but it was easy.
Parallels m2 speed is near native, VirTualBox is LOTS slower. Also I could not get a VB VM working nicely, but I believe John did.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

>
> > fwiw - I'm happy to help where I can in getting this fixed - but my 12
> > year old macbook is now officially dead; so no macos builds here
> > anymore. Happy to commit fixes though:)
> >
> > John - do you have any debug builds?
>

Thanks Mark! I most definitely will take you up on the offer when I can
dig in (work commitments just ramped up a bit). I don't have a debug
build, but can make one - is it safe to assume that it's a flag in
configure?


> PS I've done my building in parallels VM. You can even make a Big Sur VM
> on catelina.
> The only chicken-n-egg gotcha in Johns build is the build script is loaded
> by the build script. Can't recall my work around but it was easy.
> Parallels m2 speed is near native, VirTualBox is LOTS slower. Also I could
> not get a VB VM working nicely, but I believe John did.
>

Haven't played with Parallels myself - but I got VirtualBox working (on
a mac host) in pretty short order for High Sierra and Catalina. I have had
issues trying to get VMware working on a Linux host for macOS. There are
other solutions to VM's but those aren't appropriate discussions on this
mailing list.

Well, I tried edit mode from mythvideo and recordings (I hacked the bad
recording into my mythbackend replacing an old recording with the bad
video). Unfortunately, I was unable to reproduce the segfault with either
cutlist editor mechanism. Basically everything just worked for me...

I'm curious if there's some other underlying issue that's creating the
segfault.

James, have you tried telling mythbackend to rebuild the seektable? I think
the command is:

mythtranscode --buildindex --allkeys --showprogress --infile /path/to/file
(for a recording)
mythtranscode --video --buildindex --allkeys --showprogress
--infile /path/to/file (for mythvideo)

What database and version are you running on your backend? Perhaps there's
a mysqlclient mismatch or bug entering into the fray.

If memory serves, I believe I built older versions (and so did the scipr)
with mysql-10.2 for the python stuff and mysql57 for mysqlclient /
qt4-mysql-plugin. This mismatch issue was due to some macports not
supporting mariadb10.2 or later or mysql8. I'm working these issues out
with the macports folks currently and will post updated builds based on
mysql8 (going with the "official" mythtv database and what I run on my
backend...) when everything is in place.

...the Big Sur version that I'm using (and posted to sourceforge) is built
with mysql8 on pre-releases of the macports qt5-15.2 and
py-mysqlclient +mysql8 ports

Mark - any other thoughts on what could be causing the segfault?

On 27/01/2021 20:57, John Hoyt wrote:
> Well, I tried edit mode from mythvideo and recordings (I hacked the bad
> recording into my mythbackend replacing an old recording with the bad
> video).  Unfortunately, I was unable to reproduce the segfault with
> either cutlist editor mechanism.  Basically everything just worked for me...
>
> I'm curious if there's some other underlying issue that's creating the
> segfault.
>
> James, have you tried telling mythbackend to rebuild the seektable? I
> think the command is:
>
> mythtranscode --buildindex --allkeys --showprogress
> --infile /path/to/file (for a recording)
> mythtranscode --video --buildindex --allkeys --showprogress
> --infile /path/to/file (for mythvideo)

I have had tickets about seektable regeneration in the past, and suspect
that the most recent work on it has used the form

mythcommflag --rebuild --file ccccc_yyyymmhhmmssxx.xxx for
recordings, or
mythcommflag --rebuild --video /may/need/full/path/to/file for videos

Those commands also reset the file size. I've used them in scripts for
years. HTH...

>
> What database and version are you running on your backend?  Perhaps
> there's a mysqlclient mismatch or bug entering into the fray.
>
> If memory serves, I believe I built older versions (and so did the
> scipr) with mysql-10.2 for the python stuff and mysql57 for mysqlclient
> / qt4-mysql-plugin.  This mismatch issue was due to some macports not
> supporting mariadb10.2 or later or mysql8.  I'm working these issues out
> with the macports folks currently and will post updated builds based on
> mysql8 (going with the "official" mythtv database and what I run on my
> backend...) when everything is in place.
>
> ...the Big Sur version that I'm using (and posted to sourceforge) is
> built with mysql8 on pre-releases of the macports qt5-15.2 and
> py-mysqlclient +mysql8 ports
>
> Mark - any other thoughts on what could be causing the segfault?
>

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, Jan 27, 2021 at 5:00 PM John Pilkington <johnpilk222@gmail.com>
wrote:

> On 27/01/2021 20:57, John Hoyt wrote:
> > Well, I tried edit mode from mythvideo and recordings (I hacked the bad
> > recording into my mythbackend replacing an old recording with the bad
> > video). Unfortunately, I was unable to reproduce the segfault with
> > either cutlist editor mechanism. Basically everything just worked for
> me...
> >
> > I'm curious if there's some other underlying issue that's creating the
> > segfault.
> >
> > James, have you tried telling mythbackend to rebuild the seektable? I
> > think the command is:
> >
> > mythtranscode --buildindex --allkeys --showprogress
> > --infile /path/to/file (for a recording)
> > mythtranscode --video --buildindex --allkeys --showprogress
> > --infile /path/to/file (for mythvideo)
>
> I have had tickets about seektable regeneration in the past, and suspect
> that the most recent work on it has used the form
>
> mythcommflag --rebuild --file ccccc_yyyymmhhmmssxx.xxx for
> recordings, or
> mythcommflag --rebuild --video /may/need/full/path/to/file for videos
>
> Those commands also reset the file size. I've used them in scripts for
> years. HTH...
>

Thanks John - I'm going to have to borrow that trick on some of my
transcode scripts.

James, another thought in helping isolate the issue is trying to edit the
file from mythvideo. I.e. copy it to wherever you store you movies files,
tell myth to repair its seek table with John P's commands (or the ones I
suggested earlier) then try to edit the file.

> On 28 Jan 2021, at 7:47 am, John Hoyt <john.hoyt@gmail.com> wrote:
>
>
>
> On Wed, Jan 27, 2021 at 5:00 PM John Pilkington <johnpilk222@gmail.com> wrote:
> On 27/01/2021 20:57, John Hoyt wrote:
> > Well, I tried edit mode from mythvideo and recordings (I hacked the bad
> > recording into my mythbackend replacing an old recording with the bad
> > video). Unfortunately, I was unable to reproduce the segfault with
> > either cutlist editor mechanism. Basically everything just worked for me...
> >
> > I'm curious if there's some other underlying issue that's creating the
> > segfault.
> >
> > James, have you tried telling mythbackend to rebuild the seektable? I
> > think the command is:
> >
> > mythtranscode --buildindex --allkeys --showprogress
> > --infile /path/to/file (for a recording)
> > mythtranscode --video --buildindex --allkeys --showprogress
> > --infile /path/to/file (for mythvideo)
>
> I have had tickets about seektable regeneration in the past, and suspect
> that the most recent work on it has used the form
>
> mythcommflag --rebuild --file ccccc_yyyymmhhmmssxx.xxx for
> recordings, or
> mythcommflag --rebuild --video /may/need/full/path/to/file for videos
>
> Those commands also reset the file size. I've used them in scripts for
> years. HTH...
>
> Thanks John - I'm going to have to borrow that trick on some of my transcode scripts.
>
> James, another thought in helping isolate the issue is trying to edit the file from mythvideo. I.e. copy it to wherever you store you movies files, tell myth to repair its seek table with John P's commands (or the ones I suggested earlier) then try to edit the file.

I think the solution is good but so far mo cigar: (full output in case of ..)

[sandypit] /home/jam [1003]% mythcommflag --rebuild --file /store/10070_20210123131900.ts
2021-01-28 07:57:26.865199 C mythcommflag version: fixes/31 [v31.0-85-gd3088629de] www.mythtv.org
2021-01-28 07:57:26.865218 C Qt version: compile: 5.12.7, runtime: 5.12.7
MythTV Commercial Flagger, building seek table for:
Speed
Rebuild started at Thu Jan 28 07:57:27 2021
2021-01-28 07:57:27.885319 E No locale defaults file for en_AU, skipping
Rebuild completed at Thu Jan 28 07:58:29 2021
2021-01-28 07:58:29.139244 E decoding error End of file (-541478725)

EDIT - crash

[sandypit] /home/jam [1004]% mythffprobe /store/10070_20210123131900.ts
ffprobe version v31.0-85-gd3088629de Copyright (c) 2007-2019 the FFmpeg developers
built with gcc 7 (SUSE Linux)
configuration: --arch=x86 --sysinclude=/usr/include --cc='ccache gcc' --cxx='ccache g++' --ld=gcc --cpu=generic --target_os=linux --pkg_config=pkg-config --prefix=/usr/local --libdir=/usr/local/lib --as=gcc --objcc=gcc --dep_cc=gcc --host_cc=gcc --host_ld=gcc --disable-cross-compile --disable-libmp3lame --disable-libx264 --disable-libx265 --disable-libvpx --disable-libxvid --enable-vdpau --enable-libxml2 --enable-libass --disable-dxva2 --enable-libbluray --disable-libfontconfig --disable-libfreetype --disable-libiec61883 --disable-crystalhd --disable-sdl2 --disable-ffplay --enable-vaapi --enable-libdrm --extra-cflags=' -w' --extra-ldflags= --enable-stripping --strip='echo skipping strip' --disable-manpages --disable-podpages --disable-doc --disable-nvenc --enable-shared --disable-static --enable-gpl --enable-pic --disable-demuxer=mpegtsraw --disable-indev=dshow
libavutil 56. 31.100 / 56. 31.100
libavcodec 58. 54.100 / 58. 54.100
libavformat 58. 29.100 / 58. 29.100
libavdevice 58. 8.100 / 58. 8.100
libavfilter 7. 57.100 / 7. 57.100
libswscale 5. 5.100 / 5. 5.100
libswresample 3. 5.100 / 3. 5.100
libpostproc 55. 5.100 / 55. 5.100
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] decode_slice_header error
[h264 @ 0x1f21bc0] no frame!
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] decode_slice_header error
[h264 @ 0x1f21bc0] no frame!
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] decode_slice_header error
[h264 @ 0x1f21bc0] no frame!
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] decode_slice_header error
[h264 @ 0x1f21bc0] no frame!
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] decode_slice_header error
[h264 @ 0x1f21bc0] no frame!
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] decode_slice_header error
[h264 @ 0x1f21bc0] no frame!
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] decode_slice_header error
[h264 @ 0x1f21bc0] no frame!
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] decode_slice_header error
[h264 @ 0x1f21bc0] no frame!
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] SPS unavailable in decode_picture_timing
[h264 @ 0x1f21bc0] non-existing PPS 0 referenced
[h264 @ 0x1f21bc0] decode_slice_header error
[h264 @ 0x1f21bc0] no frame!
[mpegts @ 0x1f1db80] PES packet size mismatch
Last message repeated 1 times
Input #0, mpegts, from '/store/10070_20210123131900.ts':
Duration: 02:41:00.84, start: 6021.609933, bitrate: 5186 kb/s
Stream #0:0[0x641]: Video: h264 (High), yuv420p(tv, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x643](eng): Audio: ac3, 48000 Hz, stereo, fltp, 384 kb/s
Stream #0:2[0x644](eng): Subtitle: dvb_teletext
Unsupported codec with id 94215 for input stream 2

james


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

> On 28 Jan 2021, at 8:09 am, James Linder <jam@tigger.ws> wrote:
>
>
>
>> On 28 Jan 2021, at 7:47 am, John Hoyt <john.hoyt@gmail.com> wrote:
>>
>>
>>
>> On Wed, Jan 27, 2021 at 5:00 PM John Pilkington <johnpilk222@gmail.com> wrote:
>> On 27/01/2021 20:57, John Hoyt wrote:
>>> Well, I tried edit mode from mythvideo and recordings (I hacked the bad
>>> recording into my mythbackend replacing an old recording with the bad
>>> video). Unfortunately, I was unable to reproduce the segfault with
>>> either cutlist editor mechanism. Basically everything just worked for me...
>>>
>>> I'm curious if there's some other underlying issue that's creating the
>>> segfault.
>>>
>>> James, have you tried telling mythbackend to rebuild the seektable? I
>>> think the command is:
>>>
>>> mythtranscode --buildindex --allkeys --showprogress
>>> --infile /path/to/file (for a recording)
>>> mythtranscode --video --buildindex --allkeys --showprogress
>>> --infile /path/to/file (for mythvideo)
>>
>> I have had tickets about seektable regeneration in the past, and suspect
>> that the most recent work on it has used the form
>>
>> mythcommflag --rebuild --file ccccc_yyyymmhhmmssxx.xxx for
>> recordings, or
>> mythcommflag --rebuild --video /may/need/full/path/to/file for videos
>>
>> Those commands also reset the file size. I've used them in scripts for
>> years. HTH...
>>
>> Thanks John - I'm going to have to borrow that trick on some of my transcode scripts.
>>
>> James, another thought in helping isolate the issue is trying to edit the file from mythvideo. I.e. copy it to wherever you store you movies files, tell myth to repair its seek table with John P's commands (or the ones I suggested earlier) then try to edit the file.

No so easy!
I put the Movie in the right place and scanned
play->E No seektable

[sandypit] /home/jam [1005]% mythcommflag --rebuild --video /store/Movies/10070_20210123131900.ts
2021-01-28 10:30:24.541249 C mythcommflag version: fixes/31 [v31.0-85-gd3088629de] www.mythtv.org
2021-01-28 10:30:24.541267 C Qt version: compile: 5.12.7, runtime: 5.12.7
MythTV Commercial Flagger, building seek table for:
/store/Movies/10070_20210123131900.ts
Rebuild started at Thu Jan 28 10:30:25 2021
2021-01-28 10:30:25.575931 E No locale defaults file for en_AU, skipping
Rebuild completed at Thu Jan 28 10:31:25 2021
2021-01-28 10:31:25.952593 E decoding error End of file (-541478725)

play->E No seektable

??

shotcut -> export
long wait

copy, scan etc
play->E No Seektable

I post the full output lest I miss or dismiss something important

[sandypit] /home/jam [1001]% mythffprobe /store/Movies/Speed.mp4
ffprobe version v31.0-85-gd3088629de Copyright (c) 2007-2019 the FFmpeg developers
built with gcc 7 (SUSE Linux)
configuration: --arch=x86 --sysinclude=/usr/include --cc='ccache gcc' --cxx='ccache g++' --ld=gcc --cpu=generic --target_os=linux --pkg_config=pkg-config --prefix=/usr/local --libdir=/usr/local/lib --as=gcc --objcc=gcc --dep_cc=gcc --host_cc=gcc --host_ld=gcc --disable-cross-compile --disable-libmp3lame --disable-libx264 --disable-libx265 --disable-libvpx --disable-libxvid --enable-vdpau --enable-libxml2 --enable-libass --disable-dxva2 --enable-libbluray --disable-libfontconfig --disable-libfreetype --disable-libiec61883 --disable-crystalhd --disable-sdl2 --disable-ffplay --enable-vaapi --enable-libdrm --extra-cflags=' -w' --extra-ldflags= --enable-stripping --strip='echo skipping strip' --disable-manpages --disable-podpages --disable-doc --disable-nvenc --enable-shared --disable-static --enable-gpl --enable-pic --disable-demuxer=mpegtsraw --disable-indev=dshow
libavutil 56. 31.100 / 56. 31.100
libavcodec 58. 54.100 / 58. 54.100
libavformat 58. 29.100 / 58. 29.100
libavdevice 58. 8.100 / 58. 8.100
libavfilter 7. 57.100 / 7. 57.100
libswscale 5. 5.100 / 5. 5.100
libswresample 3. 5.100 / 3. 5.100
libpostproc 55. 5.100 / 55. 5.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/store/Movies/Speed.mp4':
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.29.100
Duration: 02:41:00.86, start: 0.000000, bitrate: 5195 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/unknown/bt709), 1920x1080 [SAR 1:1 DAR 16:9], 4811 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 376 kb/s (default)
Metadata:
handler_name : SoundHandler

[sandypit] /home/jam [1002]% mythcommflag --rebuild --video /store/Movies/Speed.mp4
2021-01-28 16:57:05.342296 C mythcommflag version: fixes/31 [v31.0-85-gd3088629de] www.mythtv.org
2021-01-28 16:57:05.342317 C Qt version: compile: 5.12.7, runtime: 5.12.7
MythTV Commercial Flagger, building seek table for:
/store/Movies/Speed.mp4
Rebuild started at Thu Jan 28 16:57:06 2021
2021-01-28 16:57:06.358207 E No locale defaults file for en_AU, skipping
No I-frames found, rewinding...
Rebuild completed at Thu Jan 28 16:58:11 2021
2021-01-28 16:58:11.159848 E decoding error End of file (-541478725)

Is no I frames important?
Why would shotcut make only B frames?
I thought some reasonable number, say 10 Bs to every I

James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 28/01/2021 00:09, James Linder wrote:
>
>
>> On 28 Jan 2021, at 7:47 am, John Hoyt <john.hoyt@gmail.com> wrote:
>>
>>
>>
>> On Wed, Jan 27, 2021 at 5:00 PM John Pilkington <johnpilk222@gmail.com> wrote:
>> On 27/01/2021 20:57, John Hoyt wrote:
>>> Well, I tried edit mode from mythvideo and recordings (I hacked the bad
>>> recording into my mythbackend replacing an old recording with the bad
>>> video). Unfortunately, I was unable to reproduce the segfault with
>>> either cutlist editor mechanism. Basically everything just worked for me...
>>>
>>> I'm curious if there's some other underlying issue that's creating the
>>> segfault.
>>>
>>> James, have you tried telling mythbackend to rebuild the seektable? I
>>> think the command is:
>>>
>>> mythtranscode --buildindex --allkeys --showprogress
>>> --infile /path/to/file (for a recording)
>>> mythtranscode --video --buildindex --allkeys --showprogress
>>> --infile /path/to/file (for mythvideo)
>>
>> I have had tickets about seektable regeneration in the past, and suspect
>> that the most recent work on it has used the form
>>
>> mythcommflag --rebuild --file ccccc_yyyymmhhmmssxx.xxx for
>> recordings, or
>> mythcommflag --rebuild --video /may/need/full/path/to/file for videos
>>
>> Those commands also reset the file size. I've used them in scripts for
>> years. HTH...
>>
>> Thanks John - I'm going to have to borrow that trick on some of my transcode scripts.
>>
>> James, another thought in helping isolate the issue is trying to edit the file from mythvideo. I.e. copy it to wherever you store you movies files, tell myth to repair its seek table with John P's commands (or the ones I suggested earlier) then try to edit the file.
>
> I think the solution is good but so far mo cigar: (full output in case of ..)
>
> [sandypit] /home/jam [1003]% mythcommflag --rebuild --file /store/10070_20210123131900.ts
> 2021-01-28 07:57:26.865199 C mythcommflag version: fixes/31 [v31.0-85-gd3088629de] www.mythtv.org
> 2021-01-28 07:57:26.865218 C Qt version: compile: 5.12.7, runtime: 5.12.7
> MythTV Commercial Flagger, building seek table for:
> Speed
> Rebuild started at Thu Jan 28 07:57:27 2021
> 2021-01-28 07:57:27.885319 E No locale defaults file for en_AU, skipping
> Rebuild completed at Thu Jan 28 07:58:29 2021
> 2021-01-28 07:58:29.139244 E decoding error End of file (-541478725)
>
> EDIT - crash

I don't know precisely how master relates to the versions in the mac
build, but (again) this may be relevant. I started getting crashes in
the cutlist editor after a bunch of commits to master in late October.
The crashes went away after the commit that I mentioned earlier, but
editing still had occasional 20-second hangups that happened not
randomly, but unpredictably.

It's too early to be certain, but after another bunch of commits
yesterday I have not seen any of these hangups. Perhaps the
'UIButtonList' was involved again. (Thanks, Mark_K) That's in Fedora
32. Unfortunately most of my recordings have been on my el7 system,
for which I can't now build because of the taglib bump the day before...

Back to the seektable: I find the 'commflag --rebuild' recipe usually
reliable, but I don't think it will repair defective files, and it
doesn't regenerate seektables for DVB-T radio or, iirc, other formats
such as mkv or mp4.

John P
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org