arm won't start

[ x] I have checked the wiki
[ x] I have searched for similar issues

Describe the bug
I've used arm since the 1.x days... and was up to v2.1 in the 'old' code. I've been trying and failing to get the latest v2.1_dev code to work, and noticed that your branch is even newer, so have been trying that today - but running into the exact same issue...  I believe I've cleaned out the old install, and have installed / re-booted multiple times, but keep hitting the following:
sudo /usr/bin/python3 /opt/arm/arm/ripper/main.py -d sr0 | at now
warning: commands will be executed using /bin/sh
Traceback (most recent call last):
  File "/opt/arm/arm/ripper/main.py", line 18, in <module>
    from arm.ripper import logger, utils, makemkv, handbrake, identify  # noqa: E402
  File "/opt/arm/arm/ripper/__init__.py", line 2, in <module>
    from arm.ripper import logger, utils, makemkv, handbrake, identify, getkeys  # noqa F401
  File "/opt/arm/arm/ripper/utils.py", line 19, in <module>
    import arm.models.models as m
  File "/opt/arm/arm/models/models.py", line 7, in <module>
    from arm.ripper import music_brainz
  File "/opt/arm/arm/ripper/music_brainz.py", line 8, in <module>
    import arm.ripper.utils as u
AttributeError: module 'arm' has no attribute 'ripper'
job 6378 at Sun Sep 26 16:41:00 2021

It must be something stupid I'm missing??
Environment
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.6 LTS"
[ARM Release Version or if cloning from git branch/commit (run "git branch" and "git log -1" to get this)]
git branch
* v2_devel

git log -1
commit<PHONE_NUMBER>244f67aed7d63c42389f648245f9a6 (HEAD -> v2_devel, origin/v2_devel, origin/HEAD)
Merge: d13959e 5f69980
Author: 1337-server<EMAIL_ADDRESS>Date:   Sat Aug 28 02:34:57 2021 +0100

Log file
[Run the rip in DEBUG and drag and drop the log file onto this comment box]
** NONE **  please help!

If you are still using ubuntu 18 can you test the new branch https://github.com/1337-server/automatic-ripping-machine/tree/v2_ubuntu18
I have tested it in a vm, but i cant fully test as i cant pass in my drives. And my main setup is debian.
Thanks

I tried using your current branch yesterday using Ubuntu 20.04 and I had no luck getting it to work. So I will reinstall Ubuntu 18.04 and test your new branch and see how that goes.
Get Outlook for iOShttps://aka.ms/o0ukef

From: 1337-server @.>
Sent: Thursday, October 7, 2021 9:11:03 PM
To: 1337-server/automatic-ripping-machine @.>
Cc: Subscribed @.***>
Subject: Re: [1337-server/automatic-ripping-machine] arm won't start (#100)
If you are still using ubuntu 18 can you test the new branch https://github.com/1337-server/automatic-ripping-machine/tree/v2_ubuntu18
I have tested it in a vm, but i cant fully test as i cant pass in my drives. And my main setup is debian.
Thanks
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/1337-server/automatic-ripping-machine/issues/100#issuecomment-938261365, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFCMQ4JGILSFP3SV4EZXYADUFZAKPANCNFSM5EY5MRQQ.

No.

Reply to this email directly, view it on GitHubhttps://github.com/1337-server/automatic-ripping-machine/issues/100#issuecomment-938295886, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFCMQ4O4HZLKNQZP2DBU5PTUFZLZ7ANCNFSM5EY5MRQQ.

I have found a windows arm type program on GitHub that does a good job with movies but does not work with tv series.
Get Outlook for iOShttps://aka.ms/o0ukef

From: 1337-server @.>
Sent: Thursday, October 7, 2021 11:02:31 PM
To: 1337-server/automatic-ripping-machine @.>
Cc: Rick Barnett @.>; Comment @.>
Subject: Re: [1337-server/automatic-ripping-machine] arm won't start (#100)
Before you wipe can you check the arm users Mail ?
You can check it with
'Sudo -u arm'
That should tell you why it's failing. I hadn't noticed any problems with Ubuntu 20.04 at last testing, so it would be great to get more info about it.
Thanks.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/1337-server/automatic-ripping-machine/issues/100#issuecomment-938300355, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFCMQ4NKGAZAS7D3OMT27ZDUFZNMPANCNFSM5EY5MRQQ.

this is what happens when I try to start armui:
rick@ricks-arm:~$ sudo systemctl start armui
Failed to start armui.service: Unit armui.service is not loaded properly: Exec format error.
See system logs and 'systemctl status armui.service' for details.
rick@ricks-arm:~$ systemctl status armui.service
● armui.service - Arm service
Loaded: error (Reason: Exec format error)
Active: inactive (dead)
Oct 08 17:20:47 ricks-arm systemd[1]: /etc/systemd/system/armui.service:12: Executable path is not absolute: python3 /opt/arm/arm/runui.py
Oct 08 17:21:00 ricks-arm systemd[1]: /etc/systemd/system/armui.service:12: Executable path is not absolute: python3 /opt/arm/arm/runui.py
lines 1-6/6 (END)
This is the /etc/systemd/system/armui.service file
[Unit]
Description=Arm service
Added to force armui to wait for network
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
Add your path to your logfiles if you want to enable logging
Remember to remove the # at the start of the line
#StandardOutput=append:/PATH-TO-MY-LOGFILES/WebUI.log
#StandardError=append:/PATH-TO-MY-LOGFILES/WebUI.log
ExecStart=python3 /opt/arm/arm/runui.py
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target

Try changing your service file to include the full python path
It this line
ExecStart=python3 /opt/arm/arm/runui.py
to find the full path you can type which python3 in a terminal and it will display the full path you need. So if it returns /usr/bin/python3 You would update the line to read
ExecStart=/usr/bin/python3 /opt/arm/arm/runui.py
Then after saving the service file you will need to update the daemon
sudo systemctl daemon-reload
sudo systemctl enable armui
sudo systemctl start armui

Then check the status and it should be running.

After getting ARMUI to work this is the error message I am getting mail
Message 19:
From<EMAIL_ADDRESS>Thu Oct 14 10:22:22 2021
X-Original-To: arm
Subject: Output from your job       38
To<EMAIL_ADDRESS>Date: Thu, 14 Oct 2021 10:22:22 -0400 (EDT)
From<EMAIL_ADDRESS>Traceback (most recent call last):
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/engine/base.py", line
3240, in _wrap_pool_connect
return fn()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
310, in connect
return _ConnectionFairy._checkout(self)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
868, in _checkout
fairy = _ConnectionRecord.checkout(pool)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
476, in checkout
rec = pool._do_get()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/impl.py", line
256, in _do_get
return self._create_connection()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
256, in _create_connection
return _ConnectionRecord(self)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
371, in init
self.__connect()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
666, in _connect
pool.logger.debug("Error on connect(): %s", e)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/util/langhelpers.py",
line 72, in exit
with_traceback=exc_tb,
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/util/compat.py", line
207, in raise
raise exception
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
661, in __connect
self.dbapi_connection = connection = pool._invoke_creator(self)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/engine/create.py",
line 590, in connect
return dialect.connect(*cargs, **cparams)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/engine/default.py",
line 584, in connect
return self.dbapi.connect(*cargs, **cparams)
sqlite3.OperationalError: unable to open database file
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/opt/arm/arm/ripper/main.py", line 424, in
running_jobs =
db.session.query(Job).filter(Job.status.notin_(['fail', 'success']),
Job.devpath == devpath).all()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/query.py", line
2711, in all
return self._iter().all()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/query.py", line
2849, in _iter
execution_options={"_sa_orm_load_options": self.load_options},
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/session.py", line
1688, in execute
conn = self._connection_for_bind(bind)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/session.py", line
1530, in _connection_for_bind
engine, execution_options
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/session.py", line
747, in _connection_for_bind
conn = bind.connect()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/engine/base.py", line
3194, in connect
return self._connection_cls(self, close_with_result=close_with_result)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/engine/base.py", line
96, in init
else engine.raw_connection()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/engine/base.py", line
3273, in raw_connection
return self._wrap_pool_connect(self.pool.connect, _connection)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/engine/base.py", line
3244, in wrap_pool_connect
e, dialect, self
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/engine/base.py", line
2098, in handle_dbapi_exception_noconnection
sqlalchemy_exception, with_traceback=exc_info[2], from=e
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/util/compat.py", line
207, in raise
raise exception
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/engine/base.py", line
3240, in _wrap_pool_connect
return fn()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
310, in connect
return _ConnectionFairy._checkout(self)
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py",
line 868, in _checkout
fairy = _ConnectionRecord.checkout(pool)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
476, in checkout
rec = pool._do_get()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/impl.py", line
256, in _do_get
return self._create_connection()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
256, in _create_connection
return _ConnectionRecord(self)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
371, in init
self.__connect()
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
666, in _connect
pool.logger.debug("Error on connect(): %s", e)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/util/langhelpers.py",
line 72, in exit
with_traceback=exc_tb,
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/util/compat.py", line
207, in raise
raise exception
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/pool/base.py", line
661, in __connect
self.dbapi_connection = connection = pool._invoke_creator(self)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/engine/create.py",
line 590, in connect
return dialect.connect(*cargs, **cparams)
File
"/usr/local/lib/python3.6/dist-packages/sqlalchemy/engine/default.py",
line 584, in connect
return self.dbapi.connect(*cargs, **cparams)
sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) unable to
open database file
(Background on this error at: https://sqlalche.me/e/14/e3q8)
(END)

This means that it either cant find the database file or it doesnt have permission to access it.
Can you make sure the database file exist ? And did you visit /setup to create the database ?
If you did you may need to chmod the db file in a terminal to make it writeable/owned by the arm user.

I forgot to do the setup but I have fixed that, still nothing happens when i put the dvds in the drives.
Empty.log is still empty and the DVD logs are created but not populated. I insert 5 dvds but only 2 folders get created.
Here are the read write properties for arm.db.
Can you change the owner from root to the 'arm' user and see if that helps.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/1337-server/automatic-ripping-machine/issues/100#issuecomment-945042289, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFCMQ4N57HKPQ7S7W44JQ6TUHI6ORANCNFSM5EY5MRQQ.

Latest error.
Message 27 prior to creating /opt/arm/VERSION folder
Message 27:
From<EMAIL_ADDRESS>Sun Oct 17 13:51:38 2021
X-Original-To: arm
Subject: Output from your job       59
To<EMAIL_ADDRESS>Date: Sun, 17 Oct 2021 13:51:38 -0400 (EDT)
From<EMAIL_ADDRESS>-1 day, 23:54:36.626782
Traceback (most recent call last):
File "/opt/arm/arm/ripper/main.py", line 447, in
with open(os.path.join(cfg["INSTALLPATH"], 'VERSION')) as version_file:
IsADirectoryError: [Errno 21] Is a directory: '/opt/arm/VERSION'
Message 28 is with group and owner of VERSION set to arm
Message 28:
From<EMAIL_ADDRESS>Sun Oct 17 13:51:38 2021
X-Original-To: arm
Subject: Output from your job       60
To<EMAIL_ADDRESS>Date: Sun, 17 Oct 2021 13:51:38 -0400 (EDT)
From<EMAIL_ADDRESS>-1 day, 23:54:32.166795
Traceback (most recent call last):
File "/opt/arm/arm/ripper/main.py", line 447, in
with open(os.path.join(cfg["INSTALLPATH"], 'VERSION')) as version_file:
IsADirectoryError: [Errno 21] Is a directory: '/opt/arm/VERSION'
Message 29 is with group and owner of VERSION set to root
Message 29:
From<EMAIL_ADDRESS>Sun Oct 17 14:00:12 2021
X-Original-To: arm
Subject: Output from your job       62
To<EMAIL_ADDRESS>Date: Sun, 17 Oct 2021 14:00:12 -0400 (EDT)
From<EMAIL_ADDRESS>-1 day, 23:46:01.895721
-1 day, 23:51:25.274161
Traceback (most recent call last):
File "/opt/arm/arm/ripper/main.py", line 447, in
with open(os.path.join(cfg["INSTALLPATH"], 'VERSION')) as version_file:
IsADirectoryError: [Errno 21] Is a directory: '/opt/arm/VERSION'
All 3 error messages are the same

For some reason there is a problem with your file /opt/arm/VERSION
It's showing as a directory, but it should be a simple text file with no extension. Try deleting /opt/arm/VERSION and create a new file with the same name
This is the file you're missing https://github.com/1337-server/automatic-ripping-machine/blob/v2_devel/VERSION

Here is the debug disc log. There is still no info being written to empty.log. There is no e-mail being written for this disc just the disc log.
[18-10-2021 18:28:41] INFO ARM: main. Starting ARM processing at 2021-10-18 18:28:41.678644
[18-10-2021 18:28:41] DEBUG ARM: utils.check_db_version Head is: c54d68996895
[18-10-2021 18:28:41] DEBUG ARM: utils.check_db_version Database version is: c54d68996895
[18-10-2021 18:28:41] INFO ARM: utils.check_db_version Database is up to date
[18-10-2021 18:28:41] DEBUG ARM: utils.database_adder Trying to add Job
[18-10-2021 18:28:41] DEBUG ARM: utils.database_adder successfully written Job to the database
[18-10-2021 18:28:42] DEBUG ARM: utils.database_adder Trying to add Config
[18-10-2021 18:28:42] DEBUG ARM: utils.database_adder successfully written Config to the database
[18-10-2021 18:28:42] INFO ARM: main. ARM version:
[18-10-2021 18:28:42] INFO ARM: main. Python version: 3.6.9 (default, Jan 26 2021, 15:33:00) [GCC 8.4.0]
[18-10-2021 18:28:42] INFO ARM: main. User is: arm
[18-10-2021 18:28:42] INFO ARM: logger.clean_up_logs Looking for log files older than 1 days old.
[18-10-2021 18:28:42] INFO ARM: main. Job: GOT_S2_B5_DISC2
[18-10-2021 18:28:42] INFO ARM: utils.clean_old_jobs Job #7 with PID 22428 is currently running.
[18-10-2021 18:28:42] INFO ARM: utils.clean_old_jobs Job #8 with PID 22501 is currently running.
[18-10-2021 18:28:42] INFO ARM: utils.clean_old_jobs Job #9 with PID 23186 is currently running.
[18-10-2021 18:28:42] INFO ARM: utils.clean_old_jobs Job #10 with PID 23263 is currently running.
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params **** Logging udev attributes ****
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params DEVLINKS:/dev/disk/by-id/ata-HL-DT-ST_BD-RE_WH16NS60_KL4JC6E2817 /dev/disk/by-uuid/8cf90b3045690b50 /dev/cdrw /dev/disk/by-label/GOT_S2_B5_DISC2 /dev/disk/by-path/pci-0000:00:11.0-ata-2
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params DEVNAME:/dev/sr1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params DEVPATH:/devices/pci0000:00/0000:00:11.0/ata2/host1/target1:0:0/1:0:0:0/block/sr1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params DEVTYPE:disk
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_ATA:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_ATA_SATA:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_ATA_SATA_SIGNAL_RATE_GEN1:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_BUS:ata
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_BD:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_BD_R:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_BD_RE:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_CD:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_CD_R:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_CD_RW:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_DVD:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_PLUS_R:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_PLUS_RW:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_PLUS_R_DL:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_R:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_RAM:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_RW:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA_BD:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA_SESSION_COUNT:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA_STATE:complete
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA_TRACK_COUNT:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA_TRACK_COUNT_DATA:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_FOR_SEAT:block-pci-0000_00_11_0-ata-2
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_FS_LABEL:GOT_S2_B5_DISC2
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_FS_LABEL_ENC:GOT_S2_B5_DISC2
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_FS_TYPE:udf
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_FS_USAGE:filesystem
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_FS_UUID:8cf90b3045690b50
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_FS_UUID_ENC:8cf90b3045690b50
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_FS_VERSION:2.80
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_MODEL:HL-DT-ST_BD-RE_WH16NS60
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_MODEL_ENC:HL-DT-ST\x20BD-RE\x20\x20WH16NS60\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_PATH:pci-0000:00:11.0-ata-2
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_PATH_TAG:pci-0000_00_11_0-ata-2
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_REVISION:1.03
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_SERIAL:HL-DT-ST_BD-RE_WH16NS60_KL4JC6E2817
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_SERIAL_SHORT:KL4JC6E2817
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params ID_TYPE:cd
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params MAJOR:11
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params MINOR:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params SUBSYSTEM:block
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params SYSTEMD_MOUNT_DEVICE_BOUND:1
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params TAGS::systemd:seat:uaccess:
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params USEC_INITIALIZED:3451051
[18-10-2021 18:28:42] DEBUG ARM: main.log_udev_params **** End udev attributes ****
[18-10-2021 18:28:42] INFO ARM: main.main Starting Disc identification
[18-10-2021 18:28:42] DEBUG ARM: identify.identify Identify Entry point --- job ----
+--------------------+--------------------------------------------------------------+
|       Config       |                            Value                             |
+--------------------+--------------------------------------------------------------+
| _sa_instance_state |        <sqlalchemy.orm.state.InstanceState object at         |
|                    |                       0x7f04cf4e5438>                        |
|    arm_version     |                                                              |
|     year_auto      |                             None                             |
|      disctype      |                            bluray                            |
|     poster_url     |                             None                             |
|       status       |                            active                            |
|     job_length     |                             None                             |
|    year_manual     |                             None                             |
|       label        |                       GOT_S2_B5_DISC2                        |
|       stage        |                             None                             |
|  poster_url_auto   |                             None                             |
|       job_id       |                              10                              |
|        path        |                             None                             |
|     video_type     |                           unknown                            |
|    no_of_titles    |                             None                             |
| poster_url_manual  |                             None                             |
|      ejected       |                            False                             |
|  video_type_auto   |                             None                             |
|       crc_id       |                             None                             |
|      devpath       |                           /dev/sr1                           |
|       title        |                             None                             |
|      logfile       |                     GOT_S2_B5_DISC2.log                      |
| video_type_manual  |                             None                             |
|      updated       |                            False                             |
|     mountpoint     |                         /mnt/dev/sr1                         |
|     title_auto     |                             None                             |
|        pid         |                            23263                             |
|      imdb_id       |                             None                             |
|     start_time     |                  2021-10-18 18:28:41.683694                  |
|    hasnicetitle    |                            False                             |
|    title_manual    |                             None                             |
|     stop_time      |                             None                             |
|    imdb_id_auto    |                             None                             |
|      pid_hash      |<PHONE_NUMBER>571789909                      |
|        year        |                             None                             |
|       errors       |                             None                             |
|   imdb_id_manual   |                             None                             |
+--------------------+--------------------------------------------------------------+
[18-10-2021 18:28:42] INFO ARM: identify.identify Mounting disc to: /mnt/dev/sr1
[18-10-2021 18:28:46] DEBUG ARM: models.get_disc_type Found: /mnt/dev/sr1/BDMV
[18-10-2021 18:28:46] INFO ARM: identify.identify Disc identified as video
[18-10-2021 18:28:46] DEBUG ARM: identify.get_video_details Title = Game Of Thrones Season 2 Disc 2
[18-10-2021 18:28:46] DEBUG ARM: identify.get_video_details Title: Game+Of+Thrones+Season+2+Disc+2 | Year: 2012
[18-10-2021 18:28:46] DEBUG ARM: identify.get_video_details Calling webservice with title: Game+Of+Thrones+Season+2+Disc+2 and year: 2012
[18-10-2021 18:28:46] DEBUG ARM: identify.identify_loop Response = None
[18-10-2021 18:28:46] DEBUG ARM: identify.identify_loop Subtracting 1 year...
[18-10-2021 18:28:46] DEBUG ARM: identify.metadata_selector provider omdb
[18-10-2021 18:28:46] DEBUG ARM: utils.call_omdb_api omdb - http://www.omdbapi.com/?s=Game%2BOf%2BThrones%2BSeason%2B2%2BDisc%2B2&y=2011&plot=short&r=json&apikey=3f740064

Staggering the disc insertion seems to have fixed the problem but it has to be a while between discs it can't be just a few seconds. I have been waiting for the raw media disc directory to be created before inserting the next disc and that seems to work.
I tried looking at the log and as soon as disc 1 had finished this step:
DEBUG ARM: utils.database_adder Trying to add Config
DEBUG ARM: utils.database_adder successfully written Config to the database
I inserted disc 2 but this error still occurred on disc 2:
DEBUG ARM: utils.database_adder database is locked - try 0/90
DEBUG ARM: utils.database_adder Trying to add Job
You can't be impatient when it comes to inserting the individual discs.
Now that I have got this thing working I wanted to thank you for all your help and patience while a Linux newbie.

I thought everything was good and this happened:
[20-10-2021 16:32:26] INFO ARM: main. Starting ARM processing at 2021-10-20 16:32:26.052913
[20-10-2021 16:32:26] DEBUG ARM: utils.check_db_version Head is: c54d68996895
[20-10-2021 16:32:26] DEBUG ARM: utils.check_db_version Database version is: c54d68996895
[20-10-2021 16:32:26] INFO ARM: utils.check_db_version Database is up to date
[20-10-2021 16:32:26] DEBUG ARM: utils.database_adder Trying to add Job
[20-10-2021 16:32:26] DEBUG ARM: utils.database_adder successfully written Job to the database
[20-10-2021 16:32:27] DEBUG ARM: utils.database_adder Trying to add Config
[20-10-2021 16:32:27] DEBUG ARM: utils.database_adder successfully written Config to the database
[20-10-2021 16:32:27] INFO ARM: main. ARM version:
[20-10-2021 16:32:27] INFO ARM: main. Python version: 3.6.9 (default, Jan 26 2021, 15:33:00) [GCC 8.4.0]
[20-10-2021 16:32:27] INFO ARM: main. User is: arm
[20-10-2021 16:32:27] INFO ARM: logger.clean_up_logs loglife is set to 0. Removal of logs is disabled
[20-10-2021 16:32:27] INFO ARM: main. Job: 24_SEASON2_DISC3
[20-10-2021 16:32:27] INFO ARM: utils.clean_old_jobs Job #37 with PID 9317 is currently running.
[20-10-2021 16:32:27] INFO ARM: utils.clean_old_jobs Job #38 with PID 10984 is currently running.
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params **** Logging udev attributes ****
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params DEVLINKS:/dev/disk/by-uuid/2ed3890500000000 /dev/disk/by-path/pci-0000:00:11.0-ata-1 /dev/disk/by-id/ata-HL-DT-ST_BDDVDRW_CH12LS28_K9GC6QH1245 /dev/disk/by-label/24_SEASON2_DISC3 /dev/cdrom
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params DEVNAME:/dev/sr0
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params DEVPATH:/devices/pci0000:00/0000:00:11.0/ata1/host0/target0:0:0/0:0:0:0/block/sr0
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params DEVTYPE:disk
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_ATA:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_ATA_FEATURE_SET_PM:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_ATA_FEATURE_SET_PM_ENABLED:0
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_ATA_SATA:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_ATA_SATA_SIGNAL_RATE_GEN1:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_BUS:ata
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_BD:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_CD:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_CD_R:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_CD_RW:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_DVD:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_PLUS_R:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_PLUS_RW:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_PLUS_R_DL:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_R:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_RAM:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_DVD_RW:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA_DVD:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA_SESSION_COUNT:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA_STATE:complete
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA_TRACK_COUNT:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_CDROM_MEDIA_TRACK_COUNT_DATA:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_FOR_SEAT:block-pci-0000_00_11_0-ata-1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_FS_LABEL:24_SEASON2_DISC3
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_FS_LABEL_ENC:24_SEASON2_DISC3
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_FS_TYPE:udf
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_FS_USAGE:filesystem
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_FS_UUID:2ed3890500000000
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_FS_UUID_ENC:2ed3890500000000
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_FS_VERSION:1.02
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_MODEL:HL-DT-ST_BDDVDRW_CH12LS28
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_MODEL_ENC:HL-DT-ST\x20BDDVDRW\x20CH12LS28\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_PATH:pci-0000:00:11.0-ata-1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_PATH_TAG:pci-0000_00_11_0-ata-1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_REVISION:1.00
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_SERIAL:HL-DT-ST_BDDVDRW_CH12LS28_K9GC6QH1245
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_SERIAL_SHORT:K9GC6QH1245
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params ID_TYPE:cd
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params MAJOR:11
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params MINOR:0
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params SUBSYSTEM:block
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params SYSTEMD_MOUNT_DEVICE_BOUND:1
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params TAGS::systemd:uaccess:seat:
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params USEC_INITIALIZED:3255480
[20-10-2021 16:32:27] DEBUG ARM: main.log_udev_params **** End udev attributes ****
[20-10-2021 16:32:27] INFO ARM: main.main Starting Disc identification
[20-10-2021 16:32:27] DEBUG ARM: identify.identify Identify Entry point --- job ----
+--------------------+--------------------------------------------------------------+
|       Config       |                            Value                             |
+--------------------+--------------------------------------------------------------+
| _sa_instance_state |        <sqlalchemy.orm.state.InstanceState object at         |
|                    |                       0x7ff3df0f5438>                        |
|    arm_version     |                                                              |
|     year_auto      |                             None                             |
|      disctype      |                             dvd                              |
|     poster_url     |                             None                             |
|       status       |                            active                            |
|     job_length     |                             None                             |
|    year_manual     |                             None                             |
|       label        |                       24_SEASON2_DISC3                       |
|       stage        |                             None                             |
|  poster_url_auto   |                             None                             |
|        path        |                             None                             |
|       job_id       |                              38                              |
|     video_type     |                            series                            |
| poster_url_manual  |                             None                             |
|    no_of_titles    |                             None                             |
|      ejected       |                            False                             |
|       crc_id       |                             None                             |
|  video_type_auto   |                             None                             |
|       title        |                             None                             |
|      devpath       |                           /dev/sr0                           |
| video_type_manual  |                             None                             |
|      updated       |                            False                             |
|      logfile       |                     24_SEASON2_DISC3.log                     |
|     mountpoint     |                         /mnt/dev/sr0                         |
|     title_auto     |                             None                             |
|     start_time     |                  2021-10-20 16:32:26.055269                  |
|      imdb_id       |                             None                             |
|        pid         |                            10984                             |
|    hasnicetitle    |                            False                             |
|    title_manual    |                             None                             |
|    imdb_id_auto    |                             None                             |
|      pid_hash      |<PHONE_NUMBER>936963523                      |
|     stop_time      |                             None                             |
|        year        |                             None                             |
|       errors       |                             None                             |
|   imdb_id_manual   |                             None                             |
+--------------------+--------------------------------------------------------------+
[20-10-2021 16:32:27] INFO ARM: identify.identify Mounting disc to: /mnt/dev/sr0
[20-10-2021 16:32:34] DEBUG ARM: models.get_disc_type Found: /mnt/dev/sr0/VIDEO_TS
[20-10-2021 16:32:34] INFO ARM: identify.identify Disc identified as video
[20-10-2021 16:32:34] DEBUG ARM: identify.identify_dvd
+--------------------+--------------------------------------------------------------+
|       Config       |                            Value                             |
+--------------------+--------------------------------------------------------------+
| _sa_instance_state |        <sqlalchemy.orm.state.InstanceState object at         |
|                    |                       0x7ff3df0f5438>                        |
|    arm_version     |                                                              |
|     year_auto      |                             None                             |
|      disctype      |                             dvd                              |
|     poster_url     |                             None                             |
|       status       |                            active                            |
|     job_length     |                             None                             |
|    year_manual     |                             None                             |
|       label        |                       24_SEASON2_DISC3                       |
|       stage        |                             None                             |
|  poster_url_auto   |                             None                             |
|        path        |                             None                             |
|       job_id       |                              38                              |
|     video_type     |                            series                            |
| poster_url_manual  |                             None                             |
|    no_of_titles    |                             None                             |
|      ejected       |                            False                             |
|       crc_id       |                             None                             |
|  video_type_auto   |                             None                             |
|       title        |                             None                             |
|      devpath       |                           /dev/sr0                           |
| video_type_manual  |                             None                             |
|      updated       |                            False                             |
|      logfile       |                     24_SEASON2_DISC3.log                     |
|     mountpoint     |                         /mnt/dev/sr0                         |
|     title_auto     |                             None                             |
|     start_time     |                  2021-10-20 16:32:26.055269                  |
|      imdb_id       |                             None                             |
|        pid         |                            10984                             |
|    hasnicetitle    |                            False                             |
|    title_manual    |                             None                             |
|    imdb_id_auto    |                             None                             |
|      pid_hash      |<PHONE_NUMBER>936963523                      |
|     stop_time      |                             None                             |
|        year        |                             None                             |
|       errors       |                             None                             |
|   imdb_id_manual   |                             None                             |
+--------------------+--------------------------------------------------------------+
[20-10-2021 16:32:34] INFO ARM: identify.identify_dvd DVD CRC64 hash is: fc3afbc0af2b68b1
[20-10-2021 16:32:34] DEBUG ARM: identify.identify_dvd http://1337server.pythonanywhere.com/api/v1/?mode=s&crc64=fc3afbc0af2b68b1
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_dvd dvd xml - {'mode': 'search', 'results': {}, 'success': False}
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_dvd results = {}
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_dvd dvd_title_label= 24_SEASON2_DISC3_fc3afbc0af2b68b1
[20-10-2021 16:32:35] DEBUG ARM: identify.metadata_selector provider omdb
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - http://www.omdbapi.com/?s=24_SEASON2_DISC3_fc3afbc0af2b68b1&y=None&plot=short&r=json&apikey=3f740064
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - {'Response': 'False', 'Error': 'Movie not found!', 'background_url': None}
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_dvd DVD_INFO_XML: None
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop Response = None
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop Removing year...
[20-10-2021 16:32:35] DEBUG ARM: identify.metadata_selector provider omdb
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - http://www.omdbapi.com/?s=24_SEASON2_DISC3_fc3afbc0af2b68b1&y=None&plot=short&r=json&apikey=3f740064
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - {'Response': 'False', 'Error': 'Movie not found!', 'background_url': None}
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop response: None
[20-10-2021 16:32:35] DEBUG ARM: identify.get_video_details Title = 24_SEASON2_DISC3
[20-10-2021 16:32:35] DEBUG ARM: identify.get_video_details Title: 24+SEASON2+DISC3 | Year:
[20-10-2021 16:32:35] DEBUG ARM: identify.get_video_details Calling webservice with title: 24+SEASON2+DISC3 and year:
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop Response = None
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop Removing year...
[20-10-2021 16:32:35] DEBUG ARM: identify.metadata_selector provider omdb
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - http://www.omdbapi.com/?s=24%2BSEASON2%2BDISC3&y=None&plot=short&r=json&apikey=3f740064
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - {'Response': 'False', 'Error': 'Movie not found!', 'background_url': None}
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop response: None
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop Trying title: 24+SEASON2
[20-10-2021 16:32:35] DEBUG ARM: identify.metadata_selector provider omdb
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - http://www.omdbapi.com/?s=24%2BSEASON2&plot=short&r=json&apikey=3f740064
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - {'Response': 'False', 'Error': 'Movie not found!', 'background_url': None}
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop response: None
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop Removing year...
[20-10-2021 16:32:35] DEBUG ARM: identify.metadata_selector provider omdb
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - http://www.omdbapi.com/?s=24%2BSEASON2&y=None&plot=short&r=json&apikey=3f740064
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - {'Response': 'False', 'Error': 'Movie not found!', 'background_url': None}
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop Trying title: 24
[20-10-2021 16:32:35] DEBUG ARM: identify.metadata_selector provider omdb
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - http://www.omdbapi.com/?s=24&plot=short&r=json&apikey=3f740064
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - {'Response': 'False', 'Error': 'Too many results.', 'background_url': None}
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop response: None
[20-10-2021 16:32:35] DEBUG ARM: identify.identify_loop Removing year...
[20-10-2021 16:32:35] DEBUG ARM: identify.metadata_selector provider omdb
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - http://www.omdbapi.com/?s=24&y=None&plot=short&r=json&apikey=3f740064
[20-10-2021 16:32:35] DEBUG ARM: utils.call_omdb_api omdb - {'Response': 'False', 'Error': 'Too many results.', 'background_url': None}
[20-10-2021 16:32:35] INFO ARM: identify.identify Disc title Post ident -  title:24_SEASON2_DISC3 year:None video_type:series disctype: dvd
[20-10-2021 16:32:35] DEBUG ARM: identify.identify identify.job.end ----
+--------------------+--------------------------------------------------------------+
|       Config       |                            Value                             |
+--------------------+--------------------------------------------------------------+
| _sa_instance_state |        <sqlalchemy.orm.state.InstanceState object at         |
|                    |                       0x7ff3df0f5438>                        |
|    arm_version     |                                                              |
|     year_auto      |                             None                             |
|      disctype      |                             dvd                              |
|     poster_url     |                             None                             |
|       status       |                            active                            |
|     job_length     |                             None                             |
|    year_manual     |                             None                             |
|       label        |                       24_SEASON2_DISC3                       |
|       stage        |                             None                             |
|  poster_url_auto   |                             None                             |
|        path        |                             None                             |
|       job_id       |                              38                              |
|     video_type     |                            series                            |
| poster_url_manual  |                             None                             |
|    no_of_titles    |                             None                             |
|      ejected       |                            False                             |
|       crc_id       |                       fc3afbc0af2b68b1                       |
|  video_type_auto   |                             None                             |
|       title        |                       24_SEASON2_DISC3                       |
|      devpath       |                           /dev/sr0                           |
| video_type_manual  |                             None                             |
|      updated       |                            False                             |
|      logfile       |                     24_SEASON2_DISC3.log                     |
|     mountpoint     |                         /mnt/dev/sr0                         |
|     title_auto     |                             None                             |
|     start_time     |                  2021-10-20 16:32:26.055269                  |
|      imdb_id       |                             None                             |
|        pid         |                            10984                             |
|    hasnicetitle    |                            False                             |
|    title_manual    |                             None                             |
|    imdb_id_auto    |                             None                             |
|      pid_hash      |<PHONE_NUMBER>936963523                      |
|     stop_time      |                             None                             |
|        year        |                             None                             |
|       errors       |                             None                             |
|   imdb_id_manual   |                             None                             |
+--------------------+--------------------------------------------------------------+
[20-10-2021 16:32:35] DEBUG ARM: utils.job_dupe_check trying to find jobs with crc64=fc3afbc0af2b68b1
[20-10-2021 16:32:35] DEBUG ARM: utils.job_dupe_check previous rips = {}
[20-10-2021 16:32:35] DEBUG ARM: utils.job_dupe_check we have no previous rips/jobs matching this crc64
[20-10-2021 16:32:35] DEBUG ARM: selector_events.init Using selector: EpollSelector
[20-10-2021 16:32:35] INFO ARM: main.main No manual override found.
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params **** Logging ARM variables ****
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params devpath: /dev/sr0
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params mountpoint: /mnt/dev/sr0
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params title: 24_SEASON2_DISC3
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params year: None
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params video_type: series
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params hasnicetitle: False
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params label: 24_SEASON2_DISC3
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params disctype: dvd
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params **** End of ARM variables ****
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params **** Logging config parameters ****
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params skip_transcode: True
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params mainfeature: False
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params minlength: 60
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params maxlength: 99999
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params videotype: series
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params manual_wait: False
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params manual_wait_time: 0
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params ripmethod: mkv
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params mkv_args:
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params delrawfiles: False
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params hb_preset_dvd: HQ 720p30 Surround
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params hb_preset_bd: HQ 1080p30 Surround
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params hb_args_dvd: --subtitle scan -F
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params hb_args_bd: --subtitle scan -F --subtitle-burned --audio-lang-list eng --all-audio
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params raw_path: /home/arm/media/raw/
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params transcode_path: /home/arm/media/transcode/
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params completed_path: /home/arm/media/completed/
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params extras_sub: extras
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params emby_refresh: False
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params emby_server:
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params emby_port: 8096
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params notify_rip: True
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params notify_transcode: True
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params max_concurrent_transcodes: 0
[20-10-2021 16:32:35] INFO ARM: main.log_arm_params **** End of config parameters ****
[20-10-2021 16:32:35] INFO ARM: main.check_fstab Checking for fstab entry.
[20-10-2021 16:32:35] INFO ARM: main.check_fstab fstab entry is: /dev/sr0  /mnt/dev/sr0  udf,iso9660  users,noauto,exec,utf8  0  0
[20-10-2021 16:32:35] DEBUG ARM: utils.make_dir Creating directory: /home/arm/media/transcode/tv/24_SEASON2_DISC3
[20-10-2021 16:32:35] INFO ARM: main.main Processing files to: /home/arm/media/transcode/tv/24_SEASON2_DISC3
[20-10-2021 16:32:35] INFO ARM: makemkv.makemkv Starting MakeMKV rip. Method is mkv
[20-10-2021 16:32:35] DEBUG ARM: makemkv.makemkv Getting MakeMKV disc number
[20-10-2021 16:32:53] INFO ARM: makemkv.makemkv MakeMKV disc number: 4
[20-10-2021 16:32:53] INFO ARM: makemkv.makemkv Destination is /home/arm/media/raw/24_SEASON2_DISC3
[20-10-2021 16:32:53] INFO ARM: makemkv.get_track_info Using MakeMKV to get information on all the tracks on the disc.  This will take a few minutes...
[20-10-2021 16:32:53] DEBUG ARM: makemkv.get_track_info Sending command: makemkvcon -r --cache=1 info disc:4
[20-10-2021 16:33:34] INFO ARM: makemkv.get_track_info Found 4 titles
[20-10-2021 16:33:34] DEBUG ARM: utils.database_updater no_of_titles=4
[20-10-2021 16:33:40] DEBUG ARM: utils.database_updater database is locked - try 0/90
[20-10-2021 16:33:41] DEBUG ARM: utils.database_updater database is locked - try 1/90
[20-10-2021 16:33:42] DEBUG ARM: utils.database_updater database is locked - try 2/90
[20-10-2021 16:33:43] DEBUG ARM: utils.database_updater database is locked - try 3/90
[20-10-2021 16:33:44] DEBUG ARM: utils.database_updater database is locked - try 4/90
[20-10-2021 16:33:45] DEBUG ARM: utils.database_updater database is locked - try 5/90
[20-10-2021 16:33:46] DEBUG ARM: utils.database_updater database is locked - try 6/90
[20-10-2021 16:33:47] DEBUG ARM: utils.database_updater database is locked - try 7/90
[20-10-2021 16:33:48] DEBUG ARM: utils.database_updater database is locked - try 8/90
[20-10-2021 16:33:49] DEBUG ARM: utils.database_updater database is locked - try 9/90
[20-10-2021 16:33:50] DEBUG ARM: utils.database_updater database is locked - try 10/90
[20-10-2021 16:33:51] DEBUG ARM: utils.database_updater database is locked - try 11/90
[20-10-2021 16:33:52] DEBUG ARM: utils.database_updater database is locked - try 12/90
[20-10-2021 16:33:53] DEBUG ARM: utils.database_updater database is locked - try 13/90
[20-10-2021 16:33:54] DEBUG ARM: utils.database_updater database is locked - try 14/90
[20-10-2021 16:33:55] DEBUG ARM: utils.database_updater database is locked - try 15/90
[20-10-2021 16:33:56] DEBUG ARM: utils.database_updater database is locked - try 16/90
[20-10-2021 16:33:57] DEBUG ARM: utils.database_updater database is locked - try 17/90
[20-10-2021 16:33:58] DEBUG ARM: utils.database_updater database is locked - try 18/90
[20-10-2021 16:33:59] DEBUG ARM: utils.database_updater database is locked - try 19/90
[20-10-2021 16:34:00] DEBUG ARM: utils.database_updater database is locked - try 20/90
[20-10-2021 16:34:01] DEBUG ARM: utils.database_updater database is locked - try 21/90
[20-10-2021 16:34:02] DEBUG ARM: utils.database_updater database is locked - try 22/90
[20-10-2021 16:34:03] DEBUG ARM: utils.database_updater database is locked - try 23/90
[20-10-2021 16:34:04] DEBUG ARM: utils.database_updater database is locked - try 24/90
[20-10-2021 16:34:05] DEBUG ARM: utils.database_updater database is locked - try 25/90
[20-10-2021 16:34:06] DEBUG ARM: utils.database_updater database is locked - try 26/90
[20-10-2021 16:34:07] DEBUG ARM: utils.database_updater database is locked - try 27/90
[20-10-2021 16:34:08] DEBUG ARM: utils.database_updater database is locked - try 28/90
[20-10-2021 16:34:09] DEBUG ARM: utils.database_updater database is locked - try 29/90
[20-10-2021 16:34:10] DEBUG ARM: utils.database_updater database is locked - try 30/90
[20-10-2021 16:34:11] DEBUG ARM: utils.database_updater database is locked - try 31/90
[20-10-2021 16:34:12] DEBUG ARM: utils.database_updater database is locked - try 32/90
[20-10-2021 16:34:13] DEBUG ARM: utils.database_updater database is locked - try 33/90
[20-10-2021 16:34:14] DEBUG ARM: utils.database_updater database is locked - try 34/90
[20-10-2021 16:34:15] DEBUG ARM: utils.database_updater database is locked - try 35/90
[20-10-2021 16:34:16] DEBUG ARM: utils.database_updater database is locked - try 36/90
[20-10-2021 16:34:17] DEBUG ARM: utils.database_updater database is locked - try 37/90
[20-10-2021 16:34:18] DEBUG ARM: utils.database_updater database is locked - try 38/90
[20-10-2021 16:34:19] DEBUG ARM: utils.database_updater database is locked - try 39/90
[20-10-2021 16:34:20] DEBUG ARM: utils.database_updater database is locked - try 40/90
[20-10-2021 16:34:21] DEBUG ARM: utils.database_updater database is locked - try 41/90
[20-10-2021 16:34:22] DEBUG ARM: utils.database_updater database is locked - try 42/90
[20-10-2021 16:34:23] DEBUG ARM: utils.database_updater database is locked - try 43/90
[20-10-2021 16:34:24] DEBUG ARM: utils.database_updater database is locked - try 44/90
[20-10-2021 16:34:25] DEBUG ARM: utils.database_updater database is locked - try 45/90
[20-10-2021 16:34:26] DEBUG ARM: utils.database_updater database is locked - try 46/90
[20-10-2021 16:34:27] DEBUG ARM: utils.database_updater database is locked - try 47/90
[20-10-2021 16:34:28] DEBUG ARM: utils.database_updater database is locked - try 48/90
[20-10-2021 16:34:29] DEBUG ARM: utils.database_updater database is locked - try 49/90
[20-10-2021 16:34:30] DEBUG ARM: utils.database_updater database is locked - try 50/90
[20-10-2021 16:34:31] DEBUG ARM: utils.database_updater database is locked - try 51/90
[20-10-2021 16:34:32] DEBUG ARM: utils.database_updater database is locked - try 52/90
[20-10-2021 16:34:33] DEBUG ARM: utils.database_updater database is locked - try 53/90
[20-10-2021 16:34:34] DEBUG ARM: utils.database_updater database is locked - try 54/90
[20-10-2021 16:34:35] DEBUG ARM: utils.database_updater database is locked - try 55/90
[20-10-2021 16:34:36] DEBUG ARM: utils.database_updater database is locked - try 56/90
[20-10-2021 16:34:37] DEBUG ARM: utils.database_updater database is locked - try 57/90
[20-10-2021 16:34:38] DEBUG ARM: utils.database_updater database is locked - try 58/90
[20-10-2021 16:34:39] DEBUG ARM: utils.database_updater database is locked - try 59/90
[20-10-2021 16:34:40] DEBUG ARM: utils.database_updater database is locked - try 60/90
[20-10-2021 16:34:41] DEBUG ARM: utils.database_updater database is locked - try 61/90
[20-10-2021 16:34:42] DEBUG ARM: utils.database_updater database is locked - try 62/90
[20-10-2021 16:34:43] DEBUG ARM: utils.database_updater database is locked - try 63/90
[20-10-2021 16:34:44] DEBUG ARM: utils.database_updater database is locked - try 64/90
[20-10-2021 16:34:45] DEBUG ARM: utils.database_updater database is locked - try 65/90
[20-10-2021 16:34:46] DEBUG ARM: utils.database_updater database is locked - try 66/90
[20-10-2021 16:34:47] DEBUG ARM: utils.database_updater database is locked - try 67/90
[20-10-2021 16:34:48] DEBUG ARM: utils.database_updater database is locked - try 68/90
[20-10-2021 16:34:49] DEBUG ARM: utils.database_updater database is locked - try 69/90
[20-10-2021 16:34:50] DEBUG ARM: utils.database_updater database is locked - try 70/90
[20-10-2021 16:34:51] DEBUG ARM: utils.database_updater database is locked - try 71/90
[20-10-2021 16:34:52] DEBUG ARM: utils.database_updater database is locked - try 72/90
[20-10-2021 16:34:53] DEBUG ARM: utils.database_updater database is locked - try 73/90
[20-10-2021 16:34:54] DEBUG ARM: utils.database_updater database is locked - try 74/90
[20-10-2021 16:34:55] DEBUG ARM: utils.database_updater database is locked - try 75/90
[20-10-2021 16:34:56] DEBUG ARM: utils.database_updater database is locked - try 76/90
[20-10-2021 16:34:57] DEBUG ARM: utils.database_updater database is locked - try 77/90
[20-10-2021 16:34:58] DEBUG ARM: utils.database_updater database is locked - try 78/90
[20-10-2021 16:34:59] DEBUG ARM: utils.database_updater database is locked - try 79/90
[20-10-2021 16:35:00] DEBUG ARM: utils.database_updater database is locked - try 80/90
[20-10-2021 16:35:01] DEBUG ARM: utils.database_updater database is locked - try 81/90
[20-10-2021 16:35:02] DEBUG ARM: utils.database_updater database is locked - try 82/90
[20-10-2021 16:35:03] DEBUG ARM: utils.database_updater database is locked - try 83/90
[20-10-2021 16:35:04] DEBUG ARM: utils.database_updater database is locked - try 84/90
[20-10-2021 16:35:05] DEBUG ARM: utils.database_updater database is locked - try 85/90
[20-10-2021 16:35:06] DEBUG ARM: utils.database_updater database is locked - try 86/90
[20-10-2021 16:35:07] DEBUG ARM: utils.database_updater database is locked - try 87/90
[20-10-2021 16:35:08] DEBUG ARM: utils.database_updater database is locked - try 88/90
[20-10-2021 16:35:09] DEBUG ARM: utils.database_updater database is locked - try 89/90
[20-10-2021 16:35:09] DEBUG ARM: utils.put_track Track #0 Length: 2610 fps: 29.97 aspect: 16:9 Mainfeature: False Source:  makemkv
[20-10-2021 16:35:09] ERROR ARM: main. A fatal error has occurred and ARM is exiting.  See traceback below for details.
Traceback (most recent call last):
File "/opt/arm/arm/ripper/main.py", line 459, in
main(logfile, job)
File "/opt/arm/arm/ripper/main.py", line 268, in main
mkvoutpath = makemkv.makemkv(logfile, job)
File "/opt/arm/arm/ripper/makemkv.py", line 93, in makemkv
get_track_info(mdisc, job)
File "/opt/arm/arm/ripper/makemkv.py", line 238, in get_track_info
utils.put_track(job, track, seconds, aspect, fps, False, "makemkv", filename)
File "/opt/arm/arm/ripper/utils.py", line 425, in put_track
job_id=job.job_id,
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/attributes.py", line 481, in get
return self.impl.get(state, dict_)
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/attributes.py", line 926, in get
value = self._fire_loader_callables(state, key, passive)
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/attributes.py", line 957, in _fire_loader_callables
return state._load_expired(state, passive)
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/state.py", line 710, in _load_expired
self.manager.expired_attribute_loader(self, toload, passive)
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/loading.py", line 1453, in load_scalar_attributes
no_autoflush=no_autoflush,
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/loading.py", line 412, in load_on_ident
execution_options=execution_options,
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/loading.py", line 528, in load_on_pk_identity
bind_arguments=bind_arguments,
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/session.py", line 1688, in execute
conn = self._connection_for_bind(bind)
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/session.py", line 1530, in _connection_for_bind
engine, execution_options
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/session.py", line 721, in _connection_for_bind
self._assert_active()
File "/usr/local/lib/python3.6/dist-packages/sqlalchemy/orm/session.py", line 608, in _assert_active
code="7s2a",
sqlalchemy.exc.PendingRollbackError: This Session's transaction has been rolled back due to a previous exception during flush. To begin a new transaction with this Session, first issue Session.rollback(). Original exception was: (sqlite3.OperationalError) database is locked
[SQL: UPDATE job SET no_of_titles=? WHERE job.job_id = ?]
[parameters: (4, 38)]
(Background on this error at: https://sqlalche.me/e/14/e3q8) (Background on this error at: https://sqlalche.me/e/14/7s2a)

If I leave this blank will it skip the omdb lookup.
METADATA_PROVIDER: ""
On my latest TV series disc it took 6 minutes for OMDB lookup to take place and it still found the wrong TV title. I prefer using just the title info included in the DVD disc and skip all the internet look-ups.

getting rid of omdb internet look up cleared up all my problems. I can put all 5 discs in at the same time and it works fine

What part did you remove ?

I just eliminated the IMDb metadata provider parameter in the arm.yaml config file. This stopped it from going to the internet to look for tv series titles that it wasn’t going to find anyway.
Get Outlook for iOShttps://aka.ms/o0ukef

From: 1337-server @.>
Sent: Wednesday, October 20, 2021 11:54:25 PM
To: 1337-server/automatic-ripping-machine @.>
Cc: Rick Barnett @.>; Comment @.>
Subject: Re: [1337-server/automatic-ripping-machine] arm won't start (#100)
What part did you remove ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/1337-server/automatic-ripping-machine/issues/100#issuecomment-948234861, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFCMQ4L5YCRBQXONSMIRWDTUH6FHDANCNFSM5EY5MRQQ.

If you are still using ubuntu 18 can you test the new branch https://github.com/1337-server/automatic-ripping-machine/tree/v2_ubuntu18
I have tested it in a vm, but i cant fully test as i cant pass in my drives. And my main setup is debian.
Thanks

OK... so... first a HUGE apology for being absent for so long... life... work... etc. just got in the way!!!  Sorry
I have, however, been tracking the comments / updates, and after seeing a significant increase in activity over the last month or so, decided I'd have another go getting my previously working ARM updated.  I noticed this thread was closed and hoped that the issues I was having were gone.  Unfortunately, they were not... no matter what I tried, after multiple installs of the 'default' branch, I was still having the same issue - ARM simply would not start, no logs, nothing.  THEN (after several hours and lots of bad words), I re-read the thread and spotted the above comment.  Armed (ha, ha) with a bit more optimism, I wiped my still non-working install and tried with the v2_ubuntu18 branch.  PROGRESS - for the first time, I was actually able to get into the ARMUI and run setup (previous attempts had failed, even though the UI process was running).  ARMed with even more optimism, I popped a CD in... nothing.  Popped a DVD in... nothing... So... I ran the following manually
/usr/bin/python3 /opt/arm/arm/ripper/main.py -d sr0 | at now
Ah ha... permission errors... could not write the .log file for the DVD... fixed the arm/logs folder permissions.  Re-ran the above... different errors, could not write to the db... Spotted that arm/db was owned by root... Fixed that... and... I'm RIPPING!!!
Now I'm running, I just need to re-introduce the customizations I had before = ripping CDs to WAV, Flac & AAC in one go... So a BIG Thank you for whatever you did in the v2_ubuntu18 branch


[SPARK-37906][SQL] spark-sql should not pass last comment to backend

What changes were proposed in this pull request?
In https://github.com/apache/spark/pull/34815 we change back support unclosed bracketed comment to backend.
But miss the case such as
SELECT 1; --comment

SELECT 1; /* comment */

It's a common use case in sql job. We should ignore such case.
Need to clarify that when use -e, we directly pass SQL to splitSemiColon, when use -f, CliDriver will add a \n for query.
  public int processReader(BufferedReader r) throws IOException {
    StringBuilder qsb = new StringBuilder();

    String line;
    while((line = r.readLine()) != null) {
      if (!line.startsWith("--")) {
        qsb.append(line + "\n");
      }
    }

    return this.processLine(qsb.toString());
  }

So in splitSemiColon, we should consider both case.

Query at end
Passed to backend

SELECT 1; --comment
.  SELECT 1

SELECT 1;  /* comment */
SELECT 1

SELECT 1;  /* comment
SELECT 1 and /* comment

SELECT 1; /* comment SELECT 1
SELECT 1 and /* comment SELECT 1

/ * comment SELECT 1;
/ * comment SELECT 1;

Why are the changes needed?
Spark sql should not pass last entire comment   to backend
Does this PR introduce any user-facing change?
Use can write SQL script end with a comment
SELECT 1; --comment

SELECT 1; /* comment */

How was this patch tested?
  test("test -f and -3") {
    splitSemiColon("SELECT 1; --comment").asScala.foreach(x => println(s"split : ${x}"))
    splitSemiColon("SELECT 1; /* comment */").asScala.foreach(x => println(s"split : ${x}"))
    splitSemiColon("SELECT 1; /* comment").asScala.foreach(x => println(s"split : ${x}"))
    splitSemiColon("SELECT 1; /* comment select 1;")
      .asScala.foreach(x => println(s"split : ${x}"))
    splitSemiColon("/* This is a comment without end symbol SELECT 1;")
      .asScala.foreach(x => println(s"split : ${x}"))
    splitSemiColon("SELECT 1; --comment\n").asScala.foreach(x => println(s"split : ${x}"))
    splitSemiColon("SELECT 1; /* comment */\n").asScala.foreach(x => println(s"split : ${x}"))
    splitSemiColon("SELECT 1; /* comment\n").asScala.foreach(x => println(s"split : ${x}"))
    splitSemiColon("SELECT 1; /* comment select 1;\n")
      .asScala.foreach(x => println(s"split : ${x}"))
    splitSemiColon("/* This is a comment without end symbol SELECT 1;\n")
      .asScala.foreach(x => println(s"split : ${x}"))
  }

Result is
split : SELECT 1
split : SELECT 1
split : SELECT 1
split :  /* comment
split : SELECT 1
split :  /* comment select 1;
split : /* This is a comment without end symbol SELECT 1;
split : SELECT 1
split : SELECT 1
split : SELECT 1
split :  /* comment
split : SELECT 1
split :  /* comment select 1;
split : /* This is a comment without end symbol SELECT 1;

ping @cloud-fan

is it possible to add a test?

is it possible to add a test?

Added

How about current?

thanks, merging to master!


Routing to different pages

The baseline to routing, while there may be more down the line, this should have at least:

Home
All Posts
Details (even if it's not on the navbar)
Add new
Admin panel

Routing done! Added all baseline functionality for the routing and all pages that are necessary for the ap to function as intended.


Add default resource requests for Cryostat containers

While we allow the user to specify resource requirements for each Cryostat container, we currently default to no requirements. To follow operator best practices, we should at least provide default CPU/memory requests for each container [1].
[1] https://sdk.operatorframework.io/docs/best-practices/managing-resources/

We will need to consider what we be good defaults.

@ebaron Can we use the numbers in these examples for default? Or are they just for pure examples?
https://github.com/cryostatio/cryostat-operator/blob/main/docs/config.md#resource-requirements

I think most of these were arbitrarily chosen. 768MiB is probably good for Cryostat itself. @andrewazores do you have any suggestions on default resource requests for the each of the operand containers? We can skip setting default limits for now, but requests are considered mandatory.

Not really. We should probably do a bit of profiling to find out what kind of requirements the Grafana dashboard really has. jfr-datasource shouldn't need too much, though it does need to be able to load and parse JFR files, so the memory requirement there probably scales with the average size of recording a user is inspecting - much like for -reports.

Not really. We should probably do a bit of profiling to find out what kind of requirements the Grafana dashboard really has. jfr-datasource shouldn't need too much, though it does need to be able to load and parse JFR files, so the memory requirement there probably scales with the average size of recording a user is inspecting - much like for -reports.

@andrewazores What would be the average size for the recording?

What would be the average size for the recording?

That's an unanswerable question - it depends entirely on the end user and how they're using Cryostat. How long they run recordings for and how many events they capture.
How long is a piece of string?
In our development testing deployments we usually only deal with recordings on the scale of megabytes to tens of megabytes, but that isn't necessarily representative.

Edit 0: I will try the 450mb jfr file for testing. Maybe larger? Or is 450mb too large?
Edit 1: 450mb appears to give 500 status due to 29s timeout. Maybe we expect the average to be < 450mb?

450MB is a pretty big file, so to process it in under 29 seconds could take a lot of resources. A user dealing with 450MB average filesizes is going to have vastly higher baseline resource requirements than a user dealing with 4.5MB average filesizes, and especially so if they want processing to finish in a timely manner.
Anyway, your profiling steps make sense and look good to me. I would suggest modifying the Cryostat CR and adding a cryostat-reports replica, and checking the resource requirement there when you "View Report" on such a large recording that way too.

That's an unanswerable question - it depends entirely on the end user and how they're using Cryostat. How long they run recordings for and how many events they capture.

Ahhh I was thinking of something like a common use case. But i guess its not practical then. Then, any way to check what a resource request should be?

Anyway, your profiling steps make sense and look good to me. I would suggest modifying the Cryostat CR and adding a cryostat-reports replica, and checking the resource requirement there when you "View Report" on such a large recording that way too.

Ohh yess I will do that!

That's an unanswerable question - it depends entirely on the end user and how they're using Cryostat. How long they run recordings for and how many events they capture.

Ahhh I was thinking of something like a common use case. But i guess its not practical then. Then, any way to check what a resource request should be?

I think we might have to be a bit arbitrary then. Perhaps taking a 10-20 minute Profiling recording as a baseline. Of course, this should be from an application that's actually doing something during this time. Maybe the vertx-fib-demo is enough, I'm not sure. Then see what the maximum memory usage is when processing that recording in JFR Data Source and the reports generator.
Since we're only setting resource requests, containers can use additional resources if they're available on the node. This can still backfire because setting the requests too low means that our pod could get scheduled on a node with few available resources.

Yep, whatever we do here is a "best effort heuristic". Provisioning resources to suit a 10-20 minute Profiling run sounds reasonable, but for users that only ever do 30 second Continuous monitoring runs, the defaults we supply are probably way over-provisioned.
Using vertx-fib-demo as a test case baseline should be fairly reasonable, if not a little on the low side since it's quite simple compared to any real production application. Just be sure to actually visit its web page and set it to perform some Fibonacci calculations, otherwise it only sits there idling.

After starting a 15min recording on vertx-fib-demo (running fib calculations most of the times):
Opening View Report:
POD                                                     NAME                             CPU(cores)   MEMORY(bytes)
cryostat-sample-reports-797f8bf98c-72q4g                POD                              0m           0Mi
cryostat-sample-reports-797f8bf98c-72q4g                cryostat-sample-reports          1m           211Mi

Opening View In Grafana:
POD                                                     NAME                             CPU(cores)   MEMORY(bytes)
cryostat-sample-646d899d6f-zcfvt                        cryostat-sample-grafana          2m           67Mi
cryostat-sample-646d899d6f-zcfvt                        cryostat-sample-jfr-datasource   19m          224Mi
cryostat-sample-reports-797f8bf98c-72q4g                POD                              0m           0Mi
cryostat-sample-reports-797f8bf98c-72q4g                cryostat-sample-reports          1m           223Mi

Might need to run a couple more times. But any thoughts on the values for requests @ebaron @andrewazores ?

Hmm, that's a bit more than I was expecting for a 3.4MB JFR file, especially for jfr-datasource since that should be a native image. @tthvo would it be much trouble to try a 30min recording of the same and seeing how that compares in terms of JFR file size and memory usage?

yahh sure @ebaron I already have them setup so I just have run :D will give updates when done!

@ebaron Here are the new metrics with a Profiling recording for 30min (54.0MB)
After successfully upload jfr:
POD                                                     NAME                             CPU(cores)   MEMORY(bytes)
cryostat-sample-646d899d6f-j7s27                        cryostat-sample-grafana          0m           68Mi
cryostat-sample-646d899d6f-j7s27                        cryostat-sample-jfr-datasource   1m           886Mi
cryostat-sample-reports-797f8bf98c-hskqf                cryostat-sample-reports          1m           172Mi

Openning Grafana Dashboard
POD                                                     NAME                             CPU(cores)   MEMORY(bytes)
cryostat-sample-646d899d6f-j7s27                        cryostat-sample-grafana          5m           68Mi
cryostat-sample-646d899d6f-j7s27                        cryostat-sample-jfr-datasource   29m          1667Mi
cryostat-sample-reports-797f8bf98c-hskqf                cryostat-sample-reports          1m           173Mi

This is the first run. I tried again and noticed jfr-datasource increases cpu usage much more while in dashboard. Not sure why.

The high memory usage of datasource, I guess, is due to jfr data converted to grafana-compatible form being held in memory?

Wow, that's quite the jump in JFR file size and memory usage. Based on these results, I'm leaning towards just choosing 512MiB requests for jfr-datasource and cryostat-reports. 256MiB is probably not enough, but 1GiB seems like asking too much by default. @andrewazores what do you think?

The high memory usage of datasource, I guess, is due to jfr data converted to grafana-compatible form being held in memory?

I believe so

Also how about cpu usage? I guess datasource is the main concern seems it scales fast with jfr size?

Also how about cpu usage? I guess datasource is the main concern seems it scales fast with jfr size?

Maybe 20m for each based on these results? I'm a bit surprised the report generation is so light on CPU usage for larger recordings.

I'm a bit surprised the report generation is so light on CPU usage for larger recordings.

@ebaron Ahh sorry I didnt include metrics for opening reports. Here it is. Above I break the second step (opening Grafana) into 2 small steps (upload and dashboard).
Opening View Report::
POD                                                     NAME                             CPU(cores)   MEMORY(bytes)
cryostat-sample-reports-797f8bf98c-rmfvv                POD                              0m           0Mi
cryostat-sample-reports-797f8bf98c-rmfvv                cryostat-sample-reports          775m         1093Mi

No report was shown as timeout reached.

Are these tests being run with no container limits? The memory usage could be skewed if so, because the JVM will be willing to grab a lot of memory during peak processing before later running a GC and freeing that memory. I'm pretty sure we have successfully used the Grafana and report generation features on ~50MB JFR files before without allocating ~1GB of memory to those two containers.

Are these tests being run with no container limits?

@andrewazores sorry how do I check this? I did oc describe on cryostat and report. I don't see any resource request/limit. Is this the way?

Also, just a quick notice. While being idle after opening the report for 54MB jfr, the report container state:
POD                                                     NAME                             CPU(cores)   MEMORY(bytes)
cryostat-sample-reports-797f8bf98c-2st7m                cryostat-sample-reports          1m           1040Mi

Are resources not cleaned up tho?

Are these tests being run with no container limits?

@andrewazores sorry how do I check this? I did oc describe on cryostat and report. I don't see any resource request/limit. Is this the way?

I think so, but I haven't looked at this myself in a while.

Are resources not cleaned up tho?

It should be, eventually. The reports container just does its processing work and sends the response back over HTTP, nothing should be cached or otherwise retained. I would expect the GC to have run at some point and cleaned that up, but perhaps not (yet). It's also possible that the way Java allocations memory and the way OpenShift counts memory leads to misleading readouts. For example, it could be the case that the JVM sees a lot of available memory, so it allocates large chunks and internally the JVM runtime uses this for buffers and things as needed, without releasing it back to the OS until there is memory pressure to do so. That memory wouldn't actually always be in use by the Java program, but it is allocated by the process and not freed. This would be a similar scenario to https://www.linuxatemyram.com/ .
To really know what's going on inside, we could use JFR to profile the reports container... !
We build and deploy jfr-datasource as a native image so we can't hook it up to Cryostat to pull JFR data out for profiling, so we'll need to figure out something else.

Ahh understood :D Any thoughts on this issue? Since it is possible

the way OpenShift counts memory leads to misleading readouts.

How reliable are the results of oc adm top tho? I guess we need to run these checks again and multiple times. Any better ideas?

Hmm I will try to see how I would start the profiling and get these metrics as you suggested. Will updates here with new metrics :D

Setup

All below runs are checked against the vertx-fib-demo container.
All metrics are taken as max during "working" period.
All metrics are taken from Openshift Platform Metric Dashboard.
When metrics are taken:

Core metric: while doing recording.
Datasource metric: uploading jfr, setting jfr data and serving for grafana.
Grafana metric: interacting with dashboard.
Report metric: openning report view.

Results
All checks run on cluster-bot (Openshift 4.10.18).
15-min Profiling

NAME
CPU (core)
MEMORY (MiB)

core
0.067
337.3MiB

jfr-datasource
0.184
674.9MiB

cryostat-grafana-dashboard
0.009
51.56MiB

cryostat-reports
0.564
715.4 MiB

30-min Profiling

NAME
CPU (core)
MEMORY (MiB)

core
0.07
343.2MiB

jfr-datasource
0.175
672.9MiB

cryostat-grafana-dashboard
0.008
62.34MiB

cryostat-reports
0.728
714 MiB

30-min Profiling (with datasource in JVM and JMX-enabled reports)

NAME
CPU (core)
MEMORY (MiB)

core
0.065
315.2MiB

jfr-datasource
0.285
1.1GiB

cryostat-grafana-dashboard
0.006
40.89MiB

cryostat-reports
0.866
2.47GiB

Datasource image (JVM): quay.io/thvo/jfr-datasource:latest
Report with JMX-enabled (JVM): quay.io/thvo/cryostat-reports:latest  (have to modify operator to set jmx port in report's service).
Metric Screenshots
metric_screenshots.zip
JFRs (Report & Datasource)
jfr.zip

I am thinking based on these 30-min baseline.
Core:

Request.Cpu: 100m
Request.Memory: 384MiB (half of the recommended limit we suggest in docs)

Grafana: It appears to consume little, but we should stick with Grafana Doc?

Request.Cpu: 1000m
Request.Memory: 255MB

Datasource: It appears not so cpu intensive but requires lots of memory for storing datasource.

Request.Cpu: 300m
Request.Memory: 1024MiB

Report: I guess this requires more processing and memory. Not sure about this?

Request.Cpu: 1000m
Request.Memory: 768MiB

Any thoughts @andrewazores @ebaron?

Those measurements/suggestions for the main Cryostat container and the Grafana Dashboard make sense. -reports and especially jfr-datasource will scale up their resource usage along with the size of the input file, so I think we can start with a lower baseline recommendation at minimum.
If we can establish even a very approximate heuristic for jfr file size -> memory usage  for both of those containers as well as the minimum recommendation that would be awesome.

You could use cryostat-reports itself as the JVM under test while doing that, too. It's a more realistic test case than vertx-fib-demo is. Just be sure to actually ask it to produce some reports during the recordings. Preferably, use a consistent input file each time, and perform the requests at a regular interval. This way the recording size and length should be about linearly correlated.
ie take a manual recording of vertx-fib-demo while you hammer it with some requests for "large" Fibonacci numbers over a few minutes. Then download that recording. Start a Profiling recording on cryostat-reports and request it to process the original recording taken from vertx-fib-demo. Download that recording file and stop the active recording. Restart the recording and send a new request to cryostat-reports to process the recording you just took from it, then send an identical request again 30 seconds later, and another 30 seconds later, etc. until the total duration has reached your 1/2/5/10/15/20/30/60 minute mark.

Looks like I can use Openshift Metrics Dashboard to check container resource usage. This way we can check native image too. I will try to get recordings from increasing size for vertx while hammering with large sequence. Then, repeatedly load them in datasource or send to report. Might not be ideal but should give us a rough idea on this approximate heuristic in this tight timeframe.


NPM package out of sync

For some reason, it seems like the npm package does not have the latest changes.
For example, the TCPServer still exports the single bind function instead of the two separate functions for IP4 and IP6.

The as-lunatic bindings are a bit out of date and don't work with the latest vm release. @jtenner is working on bringing them back up to date. Hopefully we have again something useful soon 🤞.

This is going to be fixed when @bkolobara publishes the latest version


Trap Visibility

How this function work? i have it enable but doesnt show the traps

Traps are only visible once they are revealed client-side. If you want a helper with deep dungeon trap finding, I'll refer you to another plugin called Deep Dungeon Helper: https://raw.githubusercontent.com/Speshkitty/DalamudPlugins/main/repo.json
There is no way around this as the object simply is not sent to the client until the player either hits the trap or reveals it with a sight. This is the same as with BA and DR(N/S) traps.


add a direct label to the bar chart.

I wanted to have something like https://plot.ly/javascript/bar-charts/#bar-chart-with-direct-labels.
I do not see any field that can be used for this number.

Dear ChengMaoDSM,
At the moment there is no way to move the label inside the bar. The addition json settings could not provided this. It is a feature that need to be build into the chart widget, like we did with the heatmap.
I wil discuss this request with the product owner and will get back to you.
With kind regards, Andries

If the text is show stopper you could consider building the chart from scratch with the Any chart module.  https://appstore.home.mendix.com/link/app/106517/
https://docs.mendix.com/refguide/charts-any-configuration
Sample:
https://docs.mendix.com/refguide/charts-any-cheat-sheet#2-6-column-chart
Or use a building block from the module.
Cheers

Will not be implemented in the standard chart widgets, could be solved with any chart

Will not be implemented in the standard chart widgets, could be solved with any chart


Bug: check_status() fails after upgrading to 3.18

Hi all,
I just want to make you aware of an issue I've encountered after upgrading from 3.17 to 3.18:
CustomCheck.check_status() got an unexpected keyword argument 'subset'
This error has been raised for some of our custom health checks. I suppose it's related to this PR? https://github.com/revsys/django-health-check/pull/390
From my perspective, the new feature doesn't work with the example provided in the Readme.

Thanks for reporting this, I'm looking into it now!


Task hangs with gulp-watch

It seems that the typescript module can't handle however gulp-watch transforms the stream.
Here's a minimal example, using gulp-notify, gulp-typescript, and gulp-watch.
var gulp = require("gulp");
var notify = require("gulp-notify");
var typescript = require("gulp-typescript");
var watch = require("gulp-watch");

gulp.task("default", function() {
	return gulp.src("src/server/scripts/**/*.ts")
		.pipe(notify("Pre-Watch"))
		.pipe(watch("src/server/scripts/**/*.ts"))
		.pipe(notify("Post-Watch"))
		.pipe(typescript())
		.pipe(notify("Post-TypeScript"))
		.pipe(gulp.dest("build/client/js"))
		.pipe(notify("Scripts done!"));
});

The only messages that appear are "Pre-Watch" and "Post-Watch", meaning that gulp-typescript is getting hung up doing something?

See #82

Sounds like a good day to dump gulp-watch, thanks.


Connection Settings Plugin HTML Output

I recently had to re-image my vCheck machine, and after re-installing everything I am seeing an output in the HTML report for the Connection Settings plugin that I have never seen before.

As you can see from the screen shot, the HTML report shows a list of numbers for this plugin and I don't understand what this is telling me or why the plugin is showing anything at all.
I'm running PowerShell v3.0, PowerCLI v5.5 Release 2 Patch 1, and the latest vCheck code from the dev branch.

Yep, I found this earlier today as well. Removing Write-Host is the cause I believe, as the status messages get passed back to vCheck. We can get around this by setting display to none.

I tested it by setting:  $Display = "None"
and that changed the HTML output from what I was seeing before, to showing the results of the "Write-CustomOut" commands in the Connection Settings plugin (lines 114-134).

hmmmmm we don't actually have a case for $display = "None" around line 808. If we set details to null there it should fix this up.
"None" { $pr.Details = $null }
The Style should then only do the replacement if $pr.Details is not null. I have a bit to get done today, so will try to get a fix for this committed if I get a chance.

I added that at line 809 (the first entry under the switch statement) and ran a test.  It worked.
So this change in vCheck.ps1 and the line $Display = "None" in the Connection Settings plugin fixed it.

Yeah cool, will have to merge this change at some point...


began project and added gitignore and gitattribute

this makes it much easier to see how the lab went. Nice work.  @mcbarnhart


adding default ignore patterns for more languages: C / C++ / Java / S…

Added default Ignore patterns to support for more languages:

C/C++: Added patterns to ignore build artifacts and binaries like *.o, *.obj, *.so, *.dll, *.dylib, *.exe, *.lib, *.a, and *.pdb.
Java: Included *.class, *.jar, *.war, *.ear, and other build-related files and directories like target/, .gradle/, and build/.
Swift/Xcode: Added patterns for common Xcode and Swift files such as .build/, *.xcodeproj/, *.xcworkspace/, and other temporary state files like *.xcuserstate.
Rust: Added ignore patterns for the target/ directory and Cargo.lock.
Go: Included patterns for the bin/ and pkg/ directories.
.NET/C#: Added common patterns for .NET projects like bin/, obj/, and *.nupkg.
Ruby: Included patterns for Ruby gems, such as *.gem, .bundle/, and Gemfile.lock.

Thank you very much for this!
I plan to merge a few big PRs before this one so there might be a little refactor needed, I'll let you know here once I'm ready

Thanks for letting me know. Please let me know when you have merged them and I will be happy to refactor it and add additional functionality if needed.

Ok so now the patterns should go there:
https://github.com/cyclotruc/gitingest/blob/16def8ab9f5d6dc9c858da7238dd5aa6a7b2df50/src/gitingest/ignore_patterns.py

Added. Please review for merge thanks!

Merged, thank you very much!


Function call feature for locally deployed models

For local models like Qwen or Ollama that are less familiar, is there a plan to support the function calling feature?

@qq1005894049 Qwen (DashScope) already supports function calling, and example is here.
Ollama does not support function calling natively yet. Once it will support it, we will add it too. Closing this request as there is https://github.com/langchain4j/langchain4j/issues/318 already

Does Qwen (DashScope) only support cloud service calls? Can the locally private deployed Qwen large model support calls as well?

@jiangsier-xyz could you please comment?

Does Qwen (DashScope) only support cloud service calls? Can the locally private deployed Qwen large model support calls as well?

No, langchain4j-dashscope is a wrapper for the model service provider DashScope (by Aliyun). If we want to use some local runtime framework to run the Qwen2 model and implement the relevant interfaces of langchain4j, we will need to implement it separately.

@qq1005894049 Qwen (DashScope) already supports function calling, and example is here.
Ollama does not support function calling natively yet. Once it will support it, we will add it too. Closing this request as there is #318 already

When do you plan to release it?

@caopengan do you mean tool support for ollama? Did ther already release it?

@caopengan do you mean tool support for ollama? Did ther already release it?

No, I'm interested in whether the Qwen model supports tool calls,Because I see that version 0.32.0 is not supported yet.

Doesn't this work for you?

Doesn't this work for you?

yeah,I see, but I use a StreamingChatLanguageModel, it is still not back support tools

@jiangsier-xyz could you please comment?

@jiangsier-xyz could you please comment?

Okay, I'll do that. Thank you very much, bro


Undesirable Font Variations in Terminal

Issue Type: Bug
Steps to Reproduce:

Open the terminal (Ctrl + ~) and observe variations in the font as across the full horizontal width of the window. Download and zoom in on screenshot and you'll see that on the far left and far right of the window, the pipe characters look fine, but in the middle of the window they appear fuzzy. with text characters this significantly impacts legibility.

Does this issue occur when all extensions are disabled?: Yes
VS Code version: Code 1.42.1 (c47d83b293181d9be64f27ff093689e8e7aed054, 2020-02-11T14:45:59.656Z)
OS version: Windows_NT x64 10.0.18362

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 2592)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: enabledrasterization: enabledskia_renderer: disabled_offsurface_control: disabled_offsurface_synchronization: enabled_onvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
31.82GB (19.49GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions: none

Do you set window.zoomLevel? Can you share your settings.json file?

Yes, I set it to -1.

Settings.json:
{
    "git.autofetch": true,
    "[javascript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[javascriptreact]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[json]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[properties]": {},
    "files.exclude": {
        "**/.classpath": true,
        "**/.project": true,
        "**/.settings": true,
        "**/.factorypath": true
    },
    "[html]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "java.actionsOnPaste.organizeImports": false,
    "[sql]": {
        "editor.defaultFormatter": "bradymholt.pgformatter"
    },
    "git.pullTags": false,
    "editor.tabSize": 2,
    "diffEditor.ignoreTrimWhitespace": false,
    "[css]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "git.confirmSync": false,
    "editor.largeFileOptimizations": false,
    "[less]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "window.zoomLevel": -1
}

I recommend keeping window.zoomLevel as 0 and then change font size settings instead /duplicate https://github.com/microsoft/vscode/issues/85154

I do not like that "solution". the zoom level controls other aspects of the GUI besides the font size in the integrated terminal. By setting the zoom level to -1 other aspects of the GUI shrink down to allow more space in the editor for viewing and working with the source code. For now I will still use zoom level -1 and just pipe the terminal output to a file and view it in an editor tab, so that the font doesn't get messed up.
It is strange to me that the font inside the editor tabs doesn't get messed up but the font in the terminal does.

They're rendered differently. You can change the terminal to work like the editor by setting renderer type to "dom" but it will be slower. This is AFAICT a limitation in the web platform around canvas, I guess because canvas isn't often rendering pixel-perfect glyphs like this.
It's my hope in the future that window.zoomLevel scales all the fonts instead of just telling Electron to change the zoom level.


Server not closing

I am having an issue closing my http server when using express.  After I call /close the server continues to accept connections.  I am able to close the server when only using http and not express. Below is the snippet of code that I am using to test server.close().
var express = require('express');
var http = require('http');

var app = express();
var serv = http.createServer(app);

app.get('/close', function(req, res) {
	res.send("CLOSING");
	serv.close();
});

serv.listen(4000, function() {
	console.log("server starting");
});

What happens if you wrap serv.close() in a setTimeout?

There is no change if I wrap serv.close() in a setTimeout.

Hi @dolph2 ! Unfortunately I cannot reproduce the issue with the supplied code. Here is a full session of my attempt to reproduce. Please let me know if you have further details to reproduce, otherwise we'd have to await a PR from you to fix the issue, if there is one. It's also very important to note how Node.js's HTTP server's close method works: it stops listening on the port, though it doesn't close any existing connections, so if you have a keep-alive connection established before the close call, you can keep getting requests over that connection unless you close it manually.
$ npm i express
<EMAIL_ADDRESS>node_modules\express
├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>├──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>└──<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>
$ node -v
v0.10.33

$ cat app.js
var express = require('express');
var http = require('http');

var app = express();
var serv = http.createServer(app);

app.get('/close', function(req, res) {
    res.send("CLOSING");
    serv.close();
});

serv.listen(4000, function() {
    console.log("server starting");
});

$ node app &
[1] 1220
server starting

$ curl http://<IP_ADDRESS>:4000/close
CLOSING
[1]+  Done                    node app

$ curl http://<IP_ADDRESS>:4000/close
curl: (7) Failed connect to <IP_ADDRESS>:4000; No error

Figured it out, it was an issue with postman adding a keepalive header I was unaware of.  Thanks for your help.

Ah, glad you got it resolved :)